Caching local time zone

[David Jarvie]

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