D8579: KDevelop: project filter support in the abstractfilemanagerplugin import benchmark
noreply at phabricator.kde.org
Thu Nov 2 14:34:43 UTC 2017
mwolff added a comment.
In https://phabricator.kde.org/D8579#163409, @rjvbb wrote:
> In https://phabricator.kde.org/D8579#163353, @mwolff wrote:
> > thanks for the numbers and profile on the project filter, I guess I'll need to port it away from QRegExp to QRegularExpression, which will mean some custom parser to transfer unix style matching to regular expressions patterns. But it does seem to help (left is status quo, right is QRegularExpression with manual conversion of the default patters to regular expressions):
> > Anyhow, not really related to this patch here, but good to keep in mind for the future
> Indeed. Are those gains still visible in real world usage - it doesn't look like filtering is a bottleneck operation like the dirwatcher population currently is? In a real world project import, a properly set up filter would exclude an in-tree build directory first, thereby skipping a whole bunch of files that would otherwise be excluded one by one. (IOW, it might already be very effective to optimise the order of the entries in the default filter.)
I once again fail to understand you. What is a "properly set up filter" vs. what you are measuring here? Both should do the same thing now, no? I.e. open the project and load the configuration that contains custom filters to exclude e.g. the build dir.
Also, how would reordering default filters change anything? If you don't exclude the folder, every file will be checked - there is no way around this. Reordering filters may help in your specific situation, but not in others where other filters would result in the early-out.
To: rjvbb, #kdevelop
Cc: mwolff, kdevelop-devel, njensen, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel