> On Jan. 21, 2015, 10:10 a.m., Dominik Haumann wrote: > > processcore/processes_linux_p.cpp, line 171 > > <https://git.reviewboard.kde.org/r/121831/diff/3/?file=343197#file343197line171> > > > > Don't you change behavior here? > > > > Before, we just wrote into the varialbes. > > > > Now, we use the setters, which also sets 'changes |= Process::Gids;' > > > > Is that maybe an issue? I myself don't know the code well enough to see > > this here. > > Gregor Mi wrote: > True. Thanks for noticing. The changes will be read in > ProcessModelPrivate::processChanged when a change is signaled by > KSysGuard::Process::processChanged. Then GUI model updates are triggered. So > probably the worst that can happen is one additional GUI update when > processChanged is emitted. > > Gregor Mi wrote: > I did some analysis. There is no visible change in behaviour ksysguard. > > ProcessesLocal::Private::readProcStatus where the change in discussion > was made (setter method with change detection instead of direct assignment). > > is called by ProcessesLocal::updateProcessInfo in the same file: > > ``` > bool ProcessesLocal::updateProcessInfo( long pid, Process *process) > { > bool success = true; > QString dir = "/proc/" + QString::number(pid) + '/'; > if(!d->readProcStat(dir, process)) success = false; > if(!d->readProcStatus(dir, process)) success = false; <------------ > ... > ``` > > Then there is > > ``` > bool Processes::updateProcess( Process *ps, long ppid) > ... > ... > > bool success = updateProcessInfo(ps); <-------- > emit processChanged(ps, false); <------- > > return success; > } > ``` > > ``` > bool Processes::updateOrAddProcess( long pid) > ... > ... > Process *ps = d->mProcesses.value(pid); > if(!ps) > return addProcess(pid, ppid); > else > return updateProcess(ps, ppid); <--------- > } > ``` > > which is called e.g. every second. > > > The emitted processChanged signal is connected here: > > ``` > connect( mProcesses, SIGNAL(processChanged(KSysGuard::Process*,bool)), > this, SLOT(processChanged(KSysGuard::Process*,bool))); > ``` > > void ProcessModelPrivate::processChanged(KSysGuard::Process *process, > bool onlyTotalCpu): > > Each change on a field that was recored in > ProcessesLocal::Private::readProcStatus will emit dataChanged signal, e.g.: > > ``` > if(process->changes() & KSysGuard::Process::Uids) { > totalUpdated++; > QModelIndex index = q->createIndex(row, > ProcessModel::HeadingUser, process); > emit q->dataChanged(index, index); > } > ``` > > The dataChanged signal is from QAbstractItemModel. So as far as I can see > the worst thing could happen that the GUI is updated at more places than > needed. > > When I start ksysguard the processChanged method is called about 300 > times (1 time for each process in the list) in the update interval (every > second). > > I tried to update everything at once and circument the dataChanged of > individual items with > ``` > QModelIndex index1 = q->createIndex(row, 0, process); > QModelIndex index2 = q->createIndex(row, q->columnCount() - 1, > process); > emit q->dataChanged(index1, index2); > return; > ``` > which had not visible effect. > > So what now? Leave the setters and have maybe a performance penalty? > Remove the setters again and use references getters? Change the Process API > otherwise?
any new input? - Gregor ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121831/#review74463 ----------------------------------------------------------- On Feb. 15, 2015, 4:35 p.m., Gregor Mi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121831/ > ----------------------------------------------------------- > > (Updated Feb. 15, 2015, 4:35 p.m.) > > > Review request for KDE Base Apps, Dominik Haumann, Eike Hein, and John > Tapsell. > > > Repository: libksysguard > > > Description > ------- > > This is a follow-up to https://git.reviewboard.kde.org/r/121717/: > > In process.h there are several public fields which easily trigger BIC > changes. This RR introduces a d-ptr. > > (In a separate commit I would add the .reviewboardrc file) > > > Diffs > ----- > > processui/scripting.h 2445c0ab0d81af3283c0f6e9c5f349a3d70b0de9 > processui/scripting.cpp 76291b0ae0a26e486aa81a4ca3976ff4a47cb3c0 > processcore/processes_solaris_p.cpp > f054df4b1e762e9cbec1ff8dea78f467b878bee0 > processui/ProcessFilter.cpp ec520593fb67c777d56817f2493d40dc5ade0347 > processui/ProcessModel.cpp 53bc041110c9cdb686fef783895104969b661889 > processui/ksysguardprocesslist.cpp 4dc142e864d8353ceafc3a6735ffa81e48291420 > processcore/processes.cpp 580df8db152040f1ad075430fdce08fe7ad4ae2d > processcore/processes_atop_p.cpp 24c76e3e35f62bd8e9e705ad32cc11cbd3662601 > processcore/processes_base_p.h 71b8a9cc6ee14bf7934a0a9d3199b257b5ce1be7 > processcore/processes_linux_p.cpp 898d4fa491873fe95a8b32a5c1b85642b2e46ad5 > processcore/processes.h d09c3265333fe7e2702deaa910c5fbe4bc3ac9e6 > tests/processtest.cpp f9b36e9a3a3c2048b51f1d935f8c40de2ad8a9b8 > .reviewboardrc PRE-CREATION > CMakeLists.txt cefc86f12be684e195bd148641483e9e1734e636 > processcore/process.h b6695c0ed301dc5f0fad8ba847da811f19ebfd9a > processcore/process.cpp a38b8be71da1a51cb87f636664ebac817b1d20ab > > Diff: https://git.reviewboard.kde.org/r/121831/diff/ > > > Testing > ------- > > Compiles and runs. Data is still shown; no visible error. Unit tests succeed. > > > Thanks, > > Gregor Mi > >