D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry
David Faure
noreply at phabricator.kde.org
Fri Jan 19 08:33:37 UTC 2018
dfaure added a comment.
In https://phabricator.kde.org/D9824#193179, @rjvbb wrote:
> > That's not applicable.
>
> Did you read my actual, original request? If so you'd have seen that it's satisfied by this answer.
Then why didn't you open kdirwatch.cpp yourself to look for m_mapEntries.constBegin() like I did? It's not rocket science, and it would have moved the discussion forward.
> Also please note the final remark in the author's summary, `Note that the other backends could leverage a similar trick to speed them up.`
Correct for FAM.
Doesn't turn out to be the case for the other backends.
>> The benchmark is not synthetic, it measures exactly the use case of monitoring a large number of files and touching them all (like `git checkout anotherbranch` would do).
>
> What's the use of an application that watches the amount of files we're talking about here for changes with which it does nothing, other than benchmarking or unit-testing? We don't know how many files we're talking about here (the benchmark results only show the total amount of CPU cycles spent). I suppose it must be a really large number if walking the list takes 7 minutes. I'm pretty certain that simultaneous change of only a fraction of that number of files will cause a very significant CPU load when KDevelop starts clang-parsing them all.
clang-parsing is outside of KDirWatch's responsibilities. The point of all this is to make KDirWatch itself faster, isn't it? I thought you found it slow yourself, surely you can't object to Milian working on making it faster, whatever else the applications do after a change notification...
REPOSITORY
R244 KCoreAddons
REVISION DETAIL
https://phabricator.kde.org/D9824
To: mwolff, dfaure, rjvbb, #kdevelop, markg
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180119/85ed2eef/attachment.html>
More information about the Kde-frameworks-devel
mailing list