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

René J.V. Bertin noreply at phabricator.kde.org
Mon Nov 20 13:20:59 UTC 2017

rjvbb added a comment.

  >   It's not "asynchronous and complex", it's just a queued connection.
  Queued just means that signals are processed in order, not synchronously, right? (There's another connection type for that IIUC.)
  Taken in isolation ("in vitro") you may be right, but if you put this in real-world usage ("in vivo") it becomes a whole different matter.
  I remember that the last time I had a project import hanging (on Mac) *none* of the numerous threads were doing anything that seemed even remotely related to project import.
  As I said, I'll remove the explicit connection spec.
  >   Are you aware of https://bugreports.qt.io/browse/QTBUG-50700, maybe that is related to your experience?
  I can't exclude it in the full app but the benchmark doesn't link to QtDeclarative and the issue appears to be Linux/X11 specific. Does it still apply to Qt 5.8?
  >   Also, clearing the disk cache via "echo 1 > /proc/sys/vm/drop_caches" sometimes helps with inconsistent benchmark results ...
  That could make sense to do before each benchmark invocation but again only on Linux.
  FWIW, I'm using ZFS on Linux, and even the benchmark's project import does something at the level of the duchain cache (= write to disk). This could also explain the freak result I posted, somehow (IOW doing a manual sync before running the benchmark might make just as much sense as writing to drop_caches).

  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/11b92413/attachment.html>

More information about the KDevelop-devel mailing list