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

[René J.V. Bertin]

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).

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7995

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>