Re: KSyCoca, Thread safety, and Cache invalidation
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... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KSyCoca, Thread safety, and Cache invalidation
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.
Re: Re: KDE Applications Versioning
On Monday 13 July 2015 23:14:17 Albert Astals Cid wrote: I did a few tweaks, i still feel it seems this is the official way other than an optional way of defining the version but maybe that's just me. Hi, I have the same feeling as Albert that the current text is not clear enough that both variants (increase version by hand and using the scripted approach) are fine. What about adding an introduction paragraph like the following: - snip - Every application has an application version number that regular has to be increased to distinguish different versions of the application (e.g., features, bugfixes). When an application does not have its own release schedule but is released alongside with KDE Applications, there is also the version number of the KDE Applications release. It is the maintainer's duty to take care on increasing the version number regularly and there are specifically two possible ways: 1. increase the version number by hand for each new release 2. use the same version number as KDE Applications and let the release script update the version number In the following, we explain how to use the scripted version numbers. - snap - If it is OK this way, I can add it later today to the wiki page. Cheers, Andreas
Re: KSyCoca, Thread safety, and Cache invalidation
On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote: Actually, checking currentTime() is already the problem here (causing the IO for the timezone stuff), see http://marc.info/?l=kde-core-develm=143533622526705w=1 (the 1st paragraph part of my comment somehow turned into a second-level quote) Comparing a monotic timer (QElapsedTime) is however - at least on linux - close to cost free PLUS: one can have an entirely free do not check again during this event cycle flag. If you just need to measure duration, QElapsedTime is your tool. Do not use QTime for this, as it can be affected by clock jumps and it accesses the timezone. If you need a machine-comparable time with other systems or across reboots, use QDateTime::currentDateTimeUtc(). That avoids refreshing the timezone database to convert to local time. Only use QDateTime::currentDateTime() if you want to show something to the user. There's no other valid reason. (writing to a log counts as showing to the user) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KSyCoca, Thread safety, and Cache invalidation
On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote: On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote: On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: ... 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. Actually, checking currentTime() is already the problem here (causing the IO for the timezone stuff), see http://marc.info/?l=kde-core-develm=143533622526705w=1 (the 1st paragraph part of my comment somehow turned into a second-level quote) Comparing a monotic timer (QElapsedTime) is however - at least on linux - close to cost free PLUS: one can have an entirely free do not check again during this event cycle flag. Cheers, Thomas