rjvbb added a comment.
> That's not applicable. Did you read my actual, original request? If so you'd have seen that it's satisfied by this answer. 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.` > 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. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D9824 To: mwolff, dfaure, rjvbb, #kdevelop, markg Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks
