Caching local time zone
lists at astrojar.org.uk
Thu Sep 21 17:45:15 BST 2006
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
>>> 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.
>KAlarm author & maintainer.
>This email has been verified as Virus free
>Virus Protection and more available at http://www.plus.net
More information about the kde-core-devel