KDirWatch and kdevelop idle CPU usage (4.7/1.7)

[Milian Wolff]

On Monday 20 April 2015 22:34:50 René J.V. Bertin wrote:
> On Monday April 20 2015 18:14:42 Milian Wolff wrote:
> > On Linux it won't use polling. Not sure whether it should do it on Mac,
> > afaik it should fall-back to QFileSystemWatcher (could you check? see
> > kdirwatch.cpp
> I'm not sure what it's supposed to fall back to, but with kdelibs4 the first
> method in the list is "Stat" ... which uses a 500ms poll timer. It's
> possible that thisPolling twice a second, that could indeed explain the
> usage I'm seeing.

It's a switch that picks the "best" option available. Afaik inotify on Linux, 
then FAM, then QFSWatcher and then stat. Independently, the user afaik still 
has the ability to pick another option when multiple are available (required 
e.g. for proper NFS support).

> Anyway, QFileSystemWatcher isn't an option for the large projects where idle
> usage becomes an issue with polling: kdevelop is aborted very quickly
> because of too many open files :(

Aborted? Why that?!

> > But the code has support to configure the poll interval via env vars
> > apparently, try KDIRWATCH_POLLINTERVAL and KDIRWATCH_NFSPOLLINTERVAL.
> 
> And via PollInterval and NFSPollInterval in the DirWatch section of
> ~/.kde/share/config/kdeglobals . That's better than env. variables :)
> Setting PollInterval=2000 gives me just under 15% CPU usage once every 2s
> which is already much more acceptable.
> > Generally, you'll lose potentially a lot. E.g. changes to the file system
> > won't show up in the project manager view. This can be highly annoying and
> > you'd have to reload manually.
> 
> Changes not showing up in the project manager view is an "evil" I can live
> with if it keeps idle CPU usage down. It'd be more annoying if the
> detection of external changes to open files is affected too.

It is also affected afaik.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de