Re: KSyCoca, Thread safety, and Cache invalidation

2015-07-14 Thread David Faure
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

2015-07-14 Thread Milian Wolff
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

2015-07-14 Thread Andreas Cord-Landwehr
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

2015-07-14 Thread Thiago Macieira
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

2015-07-14 Thread Thomas Lübking

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