D7995: KDevelop: address dirwatching inefficiency (WIP/PoC)

Milian Wolff noreply at phabricator.kde.org
Mon Nov 20 09:39:23 UTC 2017

mwolff added a comment.

  In https://phabricator.kde.org/D7995#169067, @rjvbb wrote:
  > I misremembered the exact reason I use an explicit queued connection. Some results on Linux, connecting FMLJ::watchDir without explicitly queued connection:
  > Notice the last run which all of a sudden took much longer. This sort of even happened to me twice in a row, without any apparent reason like another application hogging the CPU or preempting the disk (as far as I can tell). It's not something I can reproduce at will (and it used to be easier to observer in earlier versions of this patch) but I've never seen it when using an explicitly queued connection.
  I think by now you should know my answer to this question: Use a profiler and figure out what's going on. Heck, even attaching a debugger and intermittently interrupting it manually should give you an idea of what's going on. It shouldn't be the difference between Auto and Queued connection though, since both should yield the same result, minus the code check below which is not explaining such a huge order-of-magnitude runtime performance difference.
  > How would Qt detect here that a queued connection is required? How can it know that the FileManagerListJob allocated in the same thread as the call to connect() will send the watchDir signal from another thread?
  `object` is the receiver object, `currentThread` is the thread from where the signal is being emitted. This is not rocket science.

  R32 KDevelop


To: rjvbb, #kdevelop, mwolff
Cc: aaronpuchert, arrowdodger, kfunk, dfaure, mwolff, brauch, kdevelop-devel, njensen, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171120/accc9ecc/attachment.html>

More information about the KDevelop-devel mailing list