Caching local time zone
l.lunak at suse.cz
Sat Sep 23 12:29:12 BST 2006
Dne čtvrtek 21 září 2006 16:55 David Jarvie napsal(a):
> On Thursday 21 September 13:06, Lubos Lunak wrote:
> > 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.)
KDE3, the current state of KDE4 doesn't make it that meaningul to do
performance analyses there.
> 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.
On SUSE 10.1 I have no TZ and /etc/localtime seems to be a hardlink, so that
doesn't help with finding the timezone either (and, with TZ, I wonder, how do
you change that if you change the timezone - or will that be forbidden while
KDE is running?).
> (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.)
Twice is not really the problem, the second one is cached. The problem is
that the first one is not.
> 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?
Nothing. The module of course needs to be ready before that.
> > 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
Then it's possible the problem is in the clock applet. It shouldn't need to
know about all the time zones here, yet it opens all the files.
> 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.
SUSE LINUX, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http//www.suse.cz
More information about the kde-core-devel