rjvbb added a comment.
I don't see anything unreasonable to my request, which can also be satisfied by a argued demonstration why the same approach/fix doesn't apply to other backends. AFAIAC I'm just doing my reviewers' service like it's been shown to me how that's done. If the same approach can improve the 2 main backends (one of them being the cross-platform "default" that's not specific to a minority OS) that opportunity should be seized. Let me remind everyone that it's often been pointed out to me that I had been wasting more time arguing than it would have taken to do as asked (in addition to remarks about partial fixes and workarounds). Those don't apply just to me. I'm even going to add a request. Please describe a real-world example where this change actually has a noticeable impact, and please use time rather than CPU cycles as the measure. The observation that KDevelop `sometimes exhibits similar performance issues` is a little vague. I'm one of the few KDevelop users who have voiced concerns about KDirWatch performance but those are related to the adding of new watch items. If real-world impact is in the order of a highly significant but millisecond-order reduction of reaction time to file change there may be little reason to commit this improvement now (and then risk forgetting about the rest again). My hunch is that it could be more effective then to keep this change pending and use it as a motivation to work on a more complete overhaul of the class. A final suggestion: wouldn't it be better to reorganise the code first, splitting off the different backends into different files rather than keeping them all in a single file with all the resulting #ifdefs? REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D9824 To: mwolff, dfaure, rjvbb, #kdevelop Cc: bcooksley, zimmerman, markg, #frameworks
