Caching local time zone

[Lubos Lunak]

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
> details).

 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.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
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