Caching local time zone

[David Jarvie]

On Thursday 21 September 2006 15:55, David Jarvie wrote:
>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.

And of course, the other rather important factor which could greatly increase the 
I/O activity is that all the initialisation will be repeated for each application which 
uses KSystemTimeZones (or KDateTime plus the local time zone). So we obviously 
must have a central process to do this job.

>>> 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
>
>--
>This email has been verified as Virus free
>Virus Protection and more available at http://www.plus.net