How about we revive the Performance wiki page and make it a goal for GNOME 3.8 (or 3.10) to finally reach our 2005-2007 target of a “3 seconds login time”?
Our current login performance is pretty bad. We do way too much I/O and processing. If you write an application or service that automatically starts at login, please take a long hard look at how much extra work you’re doing on a cold start. It might seem small, but it all adds up very quickly with the rest of the applications competing for resources, as you can see in the bootcharts I made for that bug report:
This is not a new problem. It’s been there since the GNOME 2.x days and has not vanished (as I hoped it would) with the GNOME 3 session. It’s something that we have to tackle and solve together, as a well-integrated desktop environment and application ecosystem.
See for yourself: log-in on a 3-5 years old computer or netbook/nettop (not on a Core i7 with a solid state drive!), and you’ll feel the pain. And then, at the other end of the spectrum (a modern computer with a SSD), we should probably have the goal that login takes 0.5 seconds or less.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Comments
23 responses to “GNOME 3 and login performance”
Yes! Thank you for caring!
My ancient box (single core AMD64 3400+) takes ages from login screen to working desktop.
If you look at the disk utilization, it appears to be a lot of activity accessing a large number of smaller files – the actual MB/s is way down. For my new system, all the core OS and home files are on SSD.
How do you generate the boot charts through to the end of login?
These days, the “bootchart” software package (which generates bootcharts on every boot and saves them in /var/log/) does not “stop” at GDM, it continues until… well I’m not sure when it stops, maybe after a set amount of time (45 secs?) or when it detects that everything is idle.
Anyway, you can thus include the activity of the gnome login by logging in immediately when the gdm prompt shows up, or using autologin (which, I was told, might be more accurate/representative?)
It’s not a question of people trying harder, it’s a question of using the information in bootchart to smartly fix problems – sometimes this is something obvious, like the firewall-cmd issue in your chart. Sometimes it’s more subtle in terms of figuring out what the blocking factors are. Rotating media and SSD are completely separate problems – rotating media, as you’ve bootcharted here is nearly 100% blocked on disk seeks. Top things we could do for disk seeks are a) extended systemd-readahead to cover the login to the user session b) reordering blocks on disk based on systemd-readahead collecting information c) look at deserializing the login process – it seems right now we are blocking on processes like evolution-calendar-server to get to the point where we have a displayed desktop.
Before looking at such low-level optimizations though, we ought to inspect our software to make sure it’s doing useful work at that time. I still have lots of respect for the performance talks Federico gave many years ago, including:
One point that stuck with me there is that in many many cases, applications do “too much work”. That typically comes before the micro-optimizations. And that generally holds true be it on a SSD or a conventional HDD.
As you hinted, we also need to check that the session happens in the right order (the shell and desktop background should show up as soon as possible, some of its contents providers could perhaps be async).
Thanks for spotlighting this. It’s a pretty embarassing problem. Tried XFCE and just about died when it logged in in 0.5 seconds.
Nice! That’s a very anoying point of gnome to me. I tryed a lot of things to improve the login performance, but it is just acceptable in new user acount, 15 seconds above gdm.
At the application level, I have previously found that
many programs are doing silly things like opening
the same files over and over again. The tool described
here can help track that down:
http://blogs.gnome.org/mortenw/2005/12/14/strace-account/
For some reason, my Arch install takes around 10-515 seconds from GDM showing up (the background), for it to show the user-list and be usable. And then it takes over 30 seconds to have a usable desktop.
My Ubuntu GNOME Remix on the same computer loads GDM right away and takes ~7 seconds to log in.
It’s weird.
My experience is much the same on Arch. Need to figure out what the hold up is.
I made a post about it on Google+ and it seems lots of Arch users are getting this issue.
When I use lightdm on Ubuntu GNOME Remix 12.10 x64 I get into a fully loaded environment rather quickly but when using gdm it takes forever. I hope that gdm can get some performance improvements since I had to replace it with lightdm because it simply took too long time.
Somebody should finally take care of the bug in gnome-settings-daemon. I’m no c coder, but it seems like an easy fix from the comments in the bug reports [1, 2] and should make gnome usable right after login.
[1] housekeeping: Needs to be a bit more clever
[2] LP:
gnome-settings-daemon extensive disk usage
Yes ! 6000 times Yes!
On my slightly older laptop it seemed really odd that gnome3 took about 5 minutes from clicking login.
Now I have the nice one with an SSD… but still, it did seem a bit odd.
(Also the extreme slowness of search in the shell was pretty weird too).
This post sounds a bit like “Hey look, I ran a simple command that showed things are slow. Why is nobody doing anything about it?!” aka the Phoronix way of talking about software.
I personally don’t consider my login time anything worth working on. There’s so many more important things to be working on, like for example getting GNOME to run on an iPhone (or at least a Samsung Galaxy) with software that’s superior to what’s running there now. When that’s done, I might look into your performance issues.
Well, it’s not just running a simple command for the sake of running that simple command: I’ve been experiencing that slowness on a daily basis for 7 years. After all this time, I think it’s a fair game to try to remind people of this issue (especially as most developers have insanely powerful machines these days) as something we can consider as part of the GNOME 3 architectural cleanup.
Login time is arguably not so important if you suspend and resume all the time (and that’s what I do, my laptop has an average uptime of one month). However, I also think of my users (family members, friends) who run GNOME on older hardware, or hardware that does not have proper suspend/resume (thanks to some chronic GPU/kernel breakage).
Actually, to flip your argument around… a fast login time would be a good feature for GNOME to have on mobile devices. Also, GNOME 3.6 reverts the user/session menu to use poweroff/restart by default instead of suspend, so you might expect some people to start doing cold logins more often too.
The thing is that you have finite developer resources. If you could spend your next month on improving startup performance or adding features to Pitivi, what would you do? What would you suggest the people that work on gnome-shell do?
Yes, we all would take better startup performance if we got it for free. But we don’t, so what now?
Well, turns out that I probably did spend a month making Pitivi start nearly instantaneously and optimizing a couple of things, but yes I understand your point.
On the other hand, someday we gotta stop adding features and go fixing longstanding bugs too, although it is not sexy/super motivating. I always thought that, along with features, the GNOME 3 rearchitecturing was a perfect opportunity for this 🙂 if I’m not mistaken, the Zeitgeist folks are already looking into their part of the problem presented here.
Features are a nice thing, but as a user I often appreciate speed and bug-freeness a lot more with applications I use daily. Speed has always been the hugest issue with my N900 phone.
(I actually use Unity and there I think a huge problem is that it still has lots of weird bugs (windows going somewhere where they are not intended) that they are not fixing and adding dubious stuff – and speed is also a major issue. I like how gnome-shell searched the applications almost instantenously when i tried it. However, it also does not find music and files and so on if I am not mistaken and that is a a nice feature of unity. Shortly, if they just fixed a couple of bugs and made it faster instead of adding new features, I would be a happy user as it is a good interface already.)
How about simply starting with disable by default policy on everything but Gnome essentials in gnome-session-properties until the user has decided to enable/configure the stuff there. well or at least provide proper description field what each item is doing there seriously wtf…
I am offended by the use of expletives in your blog post.
And I am offended by your complaining about expletives.
As far as i’m concerned, if the developpers do nothing more for the next release or two, except fixing bugs, cleaning the code, and fixing the performance, it’ll be the best feature that’s ever added to gnome.
The login performance has been biting me for years even on an core i3 laptop, not to mention my other E7500 which i don’t even dare to run gnome on it.
So please fix the (login) performance issue, there’s nothing more beautiful than a snappy, simplistic, and bug-free DE.