On Application Startup Time: Why do we have it anyway?
Recently Jason Gerard DeRose brought up a subject that I have been considering from time to time over the last 6 months or so: “Why do our desktop applications take such a long time to start up, when they don’t do that on my phone?”. So thanks, Jason, for inspiring me to blog
A few years back it was all the rave to get rid of the “login splash” – for newcomers: GNOME used to have splash screen displayed while it was loading your desktop. The mantra in the community was “Let’s login so fast that we don’t even need a splash!”. Lots of people did awesome hard work and we got to a point where we could reasonably remove that splash screen. That’s all well and good – but recent developments in the device industry has shown people that it’s not really the boot/login time that kills you, it’s the app startup time. And I confess; I totally jumped on that band wagon.
Sure – it’s annoying as heck that my Android phone takes ages (bloody ages!) to boot up. But my nerves are instantly soothed by the responsive system that comes alive. And this is something I’ve heard over and over and over again. From Apple fangirls to Android fanboys – users really dig the fast loading apps. Unrelated non-tech people have highlighted to me that the primary feature they loved on their tablet computer of choice was the fast app launching.
So my rhetorical question: “Startup time, why do we have it anyway?”. Maybe this is really a call to rally. Let’s make our Gnome apps start instantaneously!
But let me get slightly more technical. If you’ve ever set up a semi complex prototype of a Gtk+ app, some C stub code and a Glade project, you’d probably have seen that it starts up almost instantly. So why doesn’t it do that anymore when you put actual real world code in there? This is of course where it all starts to get tricky. Common things that make startup slow:
- Anything you load of disk takes time (and don’t even think about writing). More files to load is bad, badder, baddest. Also if you do it async, less apparent but still. On a related note: For some reason heavy IO of any kind messes up graphics performance under Linux. So – just really minimize that IO on startup.
- There’s a tradition to set everything up before you show the window. This avoids that your layouts will be jumping all over the screen if you show your window immediately and start populating it with data. So you need a clever way to get the widget sizes just about right before really knowing what you’ll end up putting in there. This needs clever thinking by app authors, but maybe also some clever help from toolkit writers?
- Complex data model? Maybe you have a simple on disk format that is quick to load, maybe even mmap()able, but requires lots of secondary parsing? Try to be clever and only parse what you need to show something and delay the rest until the user is distracted.
- Using spinners when waiting for data. If the window and empty widgets are there in a snap the user wont really notice the 1-2s spinny there. Otoh if you add 1-2s on startup time they’ll have that hard-to-place sluggish feeling of the system.
If we want instant app launching to be something we can do in Gnome, then it requires a big concerted effort, but definitely not insurmountable. We’d need to play around with a few techniques, someone documenting the good ones, identifying patterns and anti patterns and making it part of our documentation. Maybe adding in some support from the plumbing layers and toolkit and we could really make this sing.
Jason proposes a 250ms startup budget. A little playing around shows me that this is very ambitious with our current stack and a semi complex app (our desktop apps tend to be more complex than mobile apps, so mobile apps have the obvious advantage there). Before reading Jason’s proposition my idea was 500ms, but maybe we should really aim for the 250ms?
What’s your take on this?
(as a closing remark let me add that I deliberately didn’t put my SSD in my new laptop because I want to feel the pain. Feel the pain so that we can eradicate it also for those without SSD)