Re: GUADEC Hacking
On 4/14/05, Alan <[EMAIL PROTECTED]> wrote: > The issues I see as far as the feel of speed when starting my system > isn't once you're logged in and your session is restoring (my session is > to start nothing on login), but before, after I've typed my password > into gdm and hit enter, and the system just seems to sit there, then > eventually load the splash screen, sit some more, load some icons, sit, > then my desktop appears. The question here is which way the user perception of time passing is quicker. You can clock it all you want, but the thruth is that if the user feels it is slow, it does not matter if it is 3 or 10 seconds. Waiting around just whirling some throbber is the next-to-worse thing to do. Giving the user a menu but not the ability to launch a program at the normal rate is not good either. It does feel a bit faster presumably, since you can actually do something in the middle of the waiting period, but it still pisses people off and possibly gives the started program a bad name without a real reason. The ultimate fix for these is, of course, make the programs work instantly :) In the meanwhile, it would be interesting to see how people would react to some distraction while loading the desktop. Show them some (randomized) fullscreen animation or something until the base desktop is ready for use (panel, nautilus and applets running). And before you say "but it will take longer to start up", I realize that. The issue here is the user perception, *not* the actual loading time. But it would be interesting to see how users react. > *That* is the issue that I think needs to be > worked on (or at least, the one that I think is outside of the users > control (ie: not starting a bunch of stuff in your session). I think it would be worth it to actually separate the GNOME loading and user session loading visually in some way, so the users will know or can guess that if it takes a minute to load the desktop, it *might* be the 100 or so mozilla windows saved in their session (so something they can fix) and not GNOME itself. -- Kalle Vahlman, [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Thu, Apr 14, 2005 at 12:51:40AM +0100, Mike Hearn wrote: > On Mon, 11 Apr 2005 22:42:41 -0400, David Zeuthen wrote: > > Interestingly enough, implementing things such as disk defrag and sane > > readahead (a'la Windows XP and Mac OS X) may actually help mask the root > > problems we're seeing right now. So we better work on them before it's > > too late :-) > > > > Starting up all the programs in the session at once probably makes things > look slower than they really are, just through the thundering herd > problem. I have no statistics on this. It's wild hand waving and > intuition. > > Usually when I log in, all these things try and start at once: > > - metacity > - evolution > - nautilus > - gnome-panel, and then all the panel applets > - gaim > - xmms > - terminals > - other stuff I don't remember The issues I see as far as the feel of speed when starting my system isn't once you're logged in and your session is restoring (my session is to start nothing on login), but before, after I've typed my password into gdm and hit enter, and the system just seems to sit there, then eventually load the splash screen, sit some more, load some icons, sit, then my desktop appears. *That* is the issue that I think needs to be worked on (or at least, the one that I think is outside of the users control (ie: not starting a bunch of stuff in your session). alan -- Alan <[EMAIL PROTECTED]> - http://arcterex.net "Backups are for people who don't pray." -- big Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Hi, I did profiling of gnome login process way back in Aug 2002 on GNOME 2.0. I am not sure if its entirely correct now, but it could give some inputs. You may want to have a look at the post and related discussions at: http://mail.gnome.org/archives/desktop-devel-list/2002-August/msg00342.html Regards, Narayana On Thu, 2005-04-14 at 05:21, Mike Hearn wrote: > On Mon, 11 Apr 2005 22:42:41 -0400, David Zeuthen wrote: > > Interestingly enough, implementing things such as disk defrag and sane > > readahead (a'la Windows XP and Mac OS X) may actually help mask the root > > problems we're seeing right now. So we better work on them before it's > > too late :-) > > > > Starting up all the programs in the session at once probably makes things > look slower than they really are, just through the thundering herd > problem. I have no statistics on this. It's wild hand waving and > intuition. > > Usually when I log in, all these things try and start at once: > > - metacity > - evolution > - nautilus > - gnome-panel, and then all the panel applets > - gaim > - xmms > - terminals > - other stuff I don't remember > > Probably you could make the desktop appear quicker and feel more > responsive (even if it's actually not) by throttling things a bit. > So the file manager should start first, so the desktop appears, then the > panel, then the applets, then the WM and then the session managed apps > could be brought up. > > The trick is to avoid the Windows XP problem, where the desktop appears > right away and then hangs itself for 15 seconds while all the session apps > in the Startup folder begin :) > > > > thanks -mike > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 11 Apr 2005 22:42:41 -0400, David Zeuthen wrote: > Interestingly enough, implementing things such as disk defrag and sane > readahead (a'la Windows XP and Mac OS X) may actually help mask the root > problems we're seeing right now. So we better work on them before it's > too late :-) Starting up all the programs in the session at once probably makes things look slower than they really are, just through the thundering herd problem. I have no statistics on this. It's wild hand waving and intuition. Usually when I log in, all these things try and start at once: - metacity - evolution - nautilus - gnome-panel, and then all the panel applets - gaim - xmms - terminals - other stuff I don't remember Probably you could make the desktop appear quicker and feel more responsive (even if it's actually not) by throttling things a bit. So the file manager should start first, so the desktop appears, then the panel, then the applets, then the WM and then the session managed apps could be brought up. The trick is to avoid the Windows XP problem, where the desktop appears right away and then hangs itself for 15 seconds while all the session apps in the Startup folder begin :) thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Jamie McCracken <[EMAIL PROTECTED]> writes: > > I'm a little skeptical because IIRC the mail I posted with the > > gconf-on-startup profiling numbers only showed 2-3 seconds for GConf. > > Which is worth fixing, but by no means explains the entire login time. > > A good place to start for full data would be the "boot chart" > > profiles > > people have done. > > But those just show the start up time of the daemons. Correct me if > I'm wrong but its not easy tell from them how a big a hit they are > causing after they are up and running? It is correct that a boot chart would not be able to assign blame to libraries, but it would show whether the processes running are disk or CPU bound. If I were to profile the login process, what I would do is modify the kernel module from the sysprof profiler and make it take stack traces of tasks in the UNINTERRUPTIBLE state instead of as now in the RUNNING state. Then feed those stack traces to an unmodified sysprof and see what the profile look like. This would produce numbers on what pieces of code are actually causing disk accesses. What it wouldn't account for, is which *other* pieces of code are accessing the same memory, so the numbers would not translate directly into blame. Søren ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Havoc Pennington wrote: On Mon, 2005-04-11 at 19:09 +0100, Jamie McCracken wrote: yes we know its disk seeks that are causing the problem and secondly GConf is the most disk intensive service at start up and lastly due to its design of having loads of files that need to be read. Put all three together... I'm a little skeptical because IIRC the mail I posted with the gconf-on-startup profiling numbers only showed 2-3 seconds for GConf. Which is worth fixing, but by no means explains the entire login time. A good place to start for full data would be the "boot chart" profiles people have done. But those just show the start up time of the daemons. Correct me if I'm wrong but its not easy tell from them how a big a hit they are causing after they are up and running? What we need to know from GConfd is how often a cache miss occurs (IE that results or is likely to result in disk activity) whenever key values are requested from apps like Gnome-Panel, Nautilus and other services that are called later on in startup. Is it possible to log/extract this information? (I assume this is easy as GConfd will know whether the keys are in its cache or not). Hopefully from this we will get some idea whether it really is the main cause of all this performance sapping disk activity. jamie. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 21:59 -0400, Havoc Pennington wrote: > On Mon, 2005-04-11 at 19:09 +0100, Jamie McCracken wrote: > > yes we know its disk seeks that are causing the problem and secondly > > GConf is the most disk intensive service at start up and lastly due to > > its design of having loads of files that need to be read. Put all three > > together... > > I'm a little skeptical because IIRC the mail I posted with the > gconf-on-startup profiling numbers only showed 2-3 seconds for GConf. > Which is worth fixing, but by no means explains the entire login time. > > A good place to start for full data would be the "boot chart" profiles > people have done. Right. According to my experiments documented here (which also covers logging into a GNOME 2.8 desktop) http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01374.html things look much much better when disk caches are primed before login, data is laid out in sequential order and the footprint is low (no pun intended :-). Most of these issues, except memory footprint and minimizing disk seeks, are really nasty OS specific problems in their own right and probably out of the scope of GNOME proper. Interestingly enough, implementing things such as disk defrag and sane readahead (a'la Windows XP and Mac OS X) may actually help mask the root problems we're seeing right now. So we better work on them before it's too late :-) Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 19:09 +0100, Jamie McCracken wrote: > yes we know its disk seeks that are causing the problem and secondly > GConf is the most disk intensive service at start up and lastly due to > its design of having loads of files that need to be read. Put all three > together... I'm a little skeptical because IIRC the mail I posted with the gconf-on-startup profiling numbers only showed 2-3 seconds for GConf. Which is worth fixing, but by no means explains the entire login time. A good place to start for full data would be the "boot chart" profiles people have done. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 19:30 +0100, Ross Burton wrote: > > As GConf supports pluggable backends now, I wouldn't be surprised if a > prototype database backend could be hacked up in a day. > > Why wait for DConf (assuming it actually fixes the other problems and > doesn't end up being another system which has no advantage over the DBus > port of GConf) when GConf has the framework needed now? I would say the mmap cache is a better idea, because it's kind of a complicated headache and a half to migrate to a new config format and we should try to avoid it until we're getting larger advantages such as a shared config system that fixes some of the gconf flaws. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 19:13 +0100, Jamie McCracken wrote: > Matthias Clasen wrote: > > On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: > > > >>The culprit is pretty obviously GConf which is why I'm glad DConf is > >>considering having a DB backend to address this. The short term fixes > >>which Havoc has already suggested (moving the schema crap sideways and > >>possibly mmap'ing some things) should cut some of that down but only a > >>properly indexed database will give you both speed and memory efficiency > >>(mmap'ing stuff is obviously wasteful memory wise). > >> > > > > > > mmapping normally saves memory, since you can share the map between all > > apps, and only actually needed pages are in ram. The only thing wasted > > by a big mmap cache is address space, which is cheap. > > Not really comparable to a DB which is designed for the cases where you > need good random access performance but cant afford to bung it all in > memory. > > EG if you have a million records in GConf you will end up with a pretty > large mutli megagbyte chunk of memory being allocated. If we have a million records in GConf, we will need brain surgery before an DB backend for an hypothetical configuration system. --- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: > The culprit is pretty obviously GConf which is why I'm glad DConf is > considering having a DB backend to address this. The short term fixes > which Havoc has already suggested (moving the schema crap sideways and > possibly mmap'ing some things) should cut some of that down but only a > properly indexed database will give you both speed and memory efficiency > (mmap'ing stuff is obviously wasteful memory wise). As GConf supports pluggable backends now, I wouldn't be surprised if a prototype database backend could be hacked up in a day. Why wait for DConf (assuming it actually fixes the other problems and doesn't end up being another system which has no advantage over the DBus port of GConf) when GConf has the framework needed now? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Matthias Clasen wrote: On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: The culprit is pretty obviously GConf which is why I'm glad DConf is considering having a DB backend to address this. The short term fixes which Havoc has already suggested (moving the schema crap sideways and possibly mmap'ing some things) should cut some of that down but only a properly indexed database will give you both speed and memory efficiency (mmap'ing stuff is obviously wasteful memory wise). mmapping normally saves memory, since you can share the map between all apps, and only actually needed pages are in ram. The only thing wasted by a big mmap cache is address space, which is cheap. Not really comparable to a DB which is designed for the cases where you need good random access performance but cant afford to bung it all in memory. EG if you have a million records in GConf you will end up with a pretty large mutli megagbyte chunk of memory being allocated. With a DB, random access to indexed keys is really quick and for most DBs you can tell it how much memory to use to cache the pages. The result is the most frequently used keys end up in the cache rather than all the keys if you mmap. The performance difference between the two is mostly neglible (assuming you will get a 90% cache hit ratio on your DB which should be possible if you allocate the right amount of cache) jamie. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Sean Middleditch wrote: On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: The culprit is pretty obviously GConf which is why I'm glad DConf is considering having a DB backend to address this. The short term fixes First off, that is not at all "obvious." Any evidence to show that it's the major culprit? yes we know its disk seeks that are causing the problem and secondly GConf is the most disk intensive service at start up and lastly due to its design of having loads of files that need to be read. Put all three together... Second, DConf does not exist, let's not bring it into any discussions regarding the fixing of GConf. There is no guarantee that DConf will *ever* exist. Worry about the here and now. :) I didn't! I only mentioned the fact that is was considering using a DB - Im not saying we should wait for it as GConf will get slower as it grows in the meantime. jamie. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: > The culprit is pretty obviously GConf which is why I'm glad DConf is > considering having a DB backend to address this. The short term fixes First off, that is not at all "obvious." Any evidence to show that it's the major culprit? Second, DConf does not exist, let's not bring it into any discussions regarding the fixing of GConf. There is no guarantee that DConf will *ever* exist. Worry about the here and now. :) -- Sean Middleditch <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: > The culprit is pretty obviously GConf which is why I'm glad DConf is > considering having a DB backend to address this. The short term fixes > which Havoc has already suggested (moving the schema crap sideways and > possibly mmap'ing some things) should cut some of that down but only a > properly indexed database will give you both speed and memory efficiency > (mmap'ing stuff is obviously wasteful memory wise). > mmapping normally saves memory, since you can share the map between all apps, and only actually needed pages are in ram. The only thing wasted by a big mmap cache is address space, which is cheap. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
> If GConf is making login slow, I think we should fix GConf. :-) > > Nat Nat: http://www.google.be/search?hl=nl&client=firefox&rls=org.mozilla% 3Aen-US%3Aunofficial&q=dconf+site%3Afreedesktop.org&btnG=Zoeken&meta= http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs Ikke http://www.eikke.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
On Mon, 2005-04-11 at 18:21 +0100, Jamie McCracken wrote: > The culprit is pretty obviously GConf which is why I'm glad DConf is > considering having a DB backend to address this. The short term fixes > which Havoc has already suggested (moving the schema crap sideways and > possibly mmap'ing some things) should cut some of that down but only a > properly indexed database will give you both speed and memory efficiency > (mmap'ing stuff is obviously wasteful memory wise). If GConf is making login slow, I think we should fix GConf. :-) Nat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUADEC Hacking
Nat Friedman wrote: One of the operations I would like to see optimized is login speed. It takes a pretty long time to login on most GNOME desktops, and I think it would be great if we could improve the login time (how long it takes before icons appear on your desktop and you can use the menu or panel launcher to launch an application). I agree that its getting really poor and I have tested to see how much of this is being caused by disk seeks (rather crude test - log on so that all disk activity is cached - kill the X server and then log on again - on my machine it takes 17 seconds with lots of disk activity to log onto Gnome from a cold start whilst a hot start with very little disk activity is down to 4 seconds) The culprit is pretty obviously GConf which is why I'm glad DConf is considering having a DB backend to address this. The short term fixes which Havoc has already suggested (moving the schema crap sideways and possibly mmap'ing some things) should cut some of that down but only a properly indexed database will give you both speed and memory efficiency (mmap'ing stuff is obviously wasteful memory wise). jamie. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
