[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Caching local time zone
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2006-09-21 14:55:43
Message-ID: df9722a4c4f134d18261aa9f7b6236d3 () webmail ! plus ! net
[Download RAW message or body]

On Thursday 21 September 13:06, Lubos Lunak wrote:
> On Thursday 21 September 2006 11:04, David Jarvie wrote:
> > Using KDateTime for date/times in the local time zone can potentially
> > result in very frequent calls to KSystemTimeZones::local() which fetches
> > and returns the current local system time zone. Depending on the system,
> > that function may open and read files, and compare their contents. Even if
> > the files are still cached (as would usually be the case on a UNIX system
> > when the function calls are made in quick succession), the overhead in file
> > system function calls makes me feel uneasy when the function could be
> > called many times a second if arrays of date/time values are being
> > converted to or from the local time zone.
> 
> Ah, so that's why the class does such awful amount of unnecessary I/O? Note 
> that this does not only affect runtime but also KDE startup (since the I/O 
> cannot be cached at that time, kernel has pretty bad performance when it 
> comes to many small files and of course everybody has the clock applet). Just 
> strace -f startkde to see.

I don't know whether the clock applet has been converted to use KDateTime or \
KTimeZones yet. (KDateTime only exists on KDE 4 - I don't know  which KDE version \
you're referring to.) The amount of I/O needed by KTimeZones depends on the system. \
In the best case, where a zone.tab  file exists and the local system time zone is \
available from the TZ environment variable, there should only be a couple of files \
opened. In the  worst case (e.g. Solaris), all the files in the zoneinfo directory \
are read at initialisation, and if there is no TZ environment variable  or \
/etc/localtime link, finding the local time zone (the first time only) can also \
result in reading a lot of zoneinfo files. (Looking at the code, it's  possible that \
the same files might be read twice - at initialisation and when finding the local \
time zone. I'll investigate that.) There are a large  number of files in zoneinfo, so \
if your system falls into a worst case category, there could be a large amount of \
I/O.

> I'd first suggest rethinking the design. Say, a kded module (with the right 
> kded startup phase, see kdebase/ksmserver/README) that does whatever initial 
> checks needed, saves the current timezone to some config file and KTimeZone 
> uses only that.

What should happen during startup if an application requests time zone information \
before the kded module has run?

> Next startup the module only checks if there have been any 
> changes and does nothing if not. Checking for changes while KDE is running 
> can be done using a file watch.

KTimeZones potentially needs to know about all the system time zones, so as soon as \
an application asks for the list or refers to a non-local  one, it needs information \
on them all (just their identities, not the full details). So if there is no system \
zone.tab file, it would probably be useful  to save the computed zone.tab in a config \
file. Your suggestions might well improve things - I'll look into it.

> > Plainly, the system time zone is not going to change frequently, so I think
> > that it would be better to cache it and only reread it periodically. I
> > propose to set a timer to refresh it once a minute. Any
> > comments/objections?
> > 
> > Note that this caching applies to the time *zone* (e.g. "Europe/Paris"). It
> > has no impact on the handling of daylight saving time shifts which will
> > still be handled without any time lag.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html


[prev in list] [next in list] [prev in thread] [next in thread]