On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote: > On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: > > checking the mtime frequently can have a bad effect on the performance > > though if it's done incorrectly. There is a bug report about high CPU > > usage in Dolphin if "sort by type" is used: > > > > https://bugs.kde.org/show_bug.cgi?id=346974 > > > > According to the backtrace, the process is busy inside > > QMimeDataBase::mimeTypeForName(QString) doing time-related things and > > accessing /etc/localtime all the time, probably because of the mtime > > check that you mentioned. I don't know that Qt version was used > > though, so I'm not sure if that still applies to the most recent > > versions. > > > > (I cannot quite reproduce the problem though because there are other > > parts of Qt's mime type handling which keep my CPU even more busy than > > the time check. I should check if this still happens in recent git > > snapshots of Qt and try to investigate this further...) > > The mimetype code in Qt hasn't really changed, you won't get a difference by > upgrading Qt. > > Interesting find, though. Maybe we could check the mtime only if more than N > seconds have passed since the last check, but I wonder if even checking > that (e.g. with QElapsedTimer) has a cost in terms of syscalls...
It has. Querying the current time repeatedly is quite costly, and often shows up in code that extensively uses timers, or QDateTime::currentDateTime() etc. But it's probably still cheaper than querying on-disk meta data in the worst case, esp. on old rotary disks. Bye -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
