From kde-core-devel Sat Sep 23 11:29:12 2006 From: Lubos Lunak Date: Sat, 23 Sep 2006 11:29:12 +0000 To: kde-core-devel Subject: Re: Caching local time zone Message-Id: <200609231329.13040.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115902609119043 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@suse.cz , l.lunak@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