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
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 :-)
random
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
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
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
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
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
If GConf is making login slow, I think we should fix GConf. :-)
Nat
Nat: http://www.google.be/search?hl=nlclient=firefoxrls=org.mozilla%
3Aen-US%3Aunofficialq=dconf+site%3Afreedesktop.orgbtnG=Zoekenmeta=
http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs
Ikke
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
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
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
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
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
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
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
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
16 matches
Mail list logo
