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)
September 12th, 2011 at 22:47
Another thing to note about tablets and smartphones is that they show a transition when loading the app, whilst on regular computer nothing happens. I think this may also be a reason for the “sluggish” feeling.
September 12th, 2011 at 23:03
Also phone/tablet apps are launching from SSDs
September 13th, 2011 at 01:13
It would be interesting to see if we could automate testing of this. Pick some reference platform, start the apps and watch X until the app appears and the screen stops changing. So we could see how all the standard GNOME apps perform, and how they perform over time.
September 13th, 2011 at 01:37
Unity shows a nice soft blinking icon while the app is starting, that gets it a nice feeling. For some reason for me personally, anything that uses gnome settings (gedit, etc) takes eons to start while it grinds the disk – something is at fault there, because things like google chrome or sublime dev show up nearly instantly, always – which is very pleasant.
September 13th, 2011 at 03:17
1) Why do we have to rebuild the UI widget by widget every time? Would it be possible to cache the fully-built UI data?
2) If not #1 above, how about caching the last drawn bitmap of the UI at shutdown, and throwing that up (perhaps with a spinner or desaturation to indicate that it’s working) until it’s been properly rebuilt, then flip the buffer?
September 13th, 2011 at 04:29
I’m all for this. I recently purchased a ThinkPad T420 with the SSD option and even with this, some apps are taking a huge amount of time to load. Rhythmbox is the biggest culprit: even loading my music (admittedly a large collection, but still) from a local directory on my SSD takes upward of 20s. Long before that, the “Starting Rhythmbox…” indicator disappears and it gives no feedback that it’s actually still starting. This is bad. Very bad.
September 13th, 2011 at 06:40
I would also suggest taking a look at the loading time of apps with translations, (when a different language is set). I think this adds quite a bit of time on it’s own…
September 13th, 2011 at 08:55
The old gtk based Nokia tablets (770,N8x0 and N900) have optimized loading of apps with preloaders, maybe something to take a look at.
September 13th, 2011 at 09:10
@Hylke: Totally agreed. This is not just about improving the raw *actual* startup time, but also about adding the illusion that things are snappy.
@Robert: That’s a bit too simplistic I think. As also noted by Hylke, it’s also about the perceived startup time. Fast mapping of the main widgets but with a few spinners could disrupt your strategy. That said there still may be ways to automate this, perhaps with adding some explicit profiling code to apps.
@Vadim: The Chrome team has put enormous effort into the fast startup thing. It doesn’t come for free by not using Gnome libs…
@Michael: I am not sure 1) makes sense, perhaps only for a subset of apps. Or at the very least it requires a lot of synchronization effort from the app to have a seamless transition to the “real” state. On 2) that’s tricky to say – could also be very annoying
I’ll let some UX expert to answer that.
@dbrodie: Interesting proposition…
@onion: that’s a possibility, but I don’t think this is the modern way to solve this. It still means the same net amount of disk grinding an CPu burning. Just less visible to the user.
September 13th, 2011 at 10:18
Application Startup Time also lead to bad behavior on desktop : after I have logged in, I open many applications that I won’t use right now only to be able to go back to them faster later. This behavior is partly solved by the automatic startup of some application (like empathy, or evolution to get new messages), but I’m sure a better application startup time will also lead the users to focus on their tasks.
September 13th, 2011 at 10:26
Great idea! I really hope people take this up.
@Michael: #2 sounds insane. Why would a bitmap of the last video I watched be relevant for the next one? How would adding code to write-out a cached UI; read it in; etc. improve app startup time?
September 13th, 2011 at 10:41
Please also have a look at the new elementary os, they seem to do preloading/caching to launchh apps almost instantly, too.
http://www.omgubuntu.co.uk/2011/06/check-out-the-insane-speed-of-elementary-os-luna-video/
http://www.youtube.com/watch?v=3kvmyDR7FCo
September 13th, 2011 at 11:09
Well Maemo on N900 also goes the way of just showing a screenshot of the app before the real app appears. I hate it.
September 13th, 2011 at 12:17
A neat trick Apple does is having a per file compression in HFS+ and compressing the binaries. It is faster to decompress the binary in memory than it is to read a non-compressed binary from the disk.
September 13th, 2011 at 13:48
How come when apps start they have to alloc and populate any data structures? Why can’t the whole app, widgets, underly GLib data structures and everything else all the way down can’t be memmapped into memory? Think how many times you allocate onto the heap when an app starts. No need for it – why can’t you just copy the running apps address space into memory from the last time is was running.
Compare to something like hibernate on a laptop, or saving a Virtual Box guest os to disk. When you come to resume, you just load the whole image into memory. Why can’t apps be stored as a memory image when they aren’t running, and memmapped back into space when they’re needed again.
Then it would be a case of doing all the slow init just once, when the start the app for the very first time after install.
September 13th, 2011 at 15:40
“I deliberately didn’t put my SSD in my new laptop because I want to feel the pain” …. but smartphones and tables do not want to feel the pain so they use flash based storage which has way lower seek times then mechanical dinosaurs.
#1 bottleneck when starting apps is the disk (hence why it does not matter much that phones/tablets have way slower cpus).
September 14th, 2011 at 09:38
Yeah…SSDs. There’s not a single app I run which takes more than two seconds to launch. Yes, including LibreOffice.
September 14th, 2011 at 13:03
@kamstrup I’m so happy you’re excited about this!
I think fast app startup is fairly easy if you start profiling it early in the development and just hold your line in the sand. But I totally agree that we need to document patterns and anti-patterns so people don’t waste time wondering in the dark.
For example, I’ve personally had good results with my GObject.idle_add() trick, but it’s not necessarily the best approach… yet I haven’t really found advice anywhere on this problem, don’t know of any better approach.
All in all I think the Gnome stack is a very strong platform (otherwise I wouldn’t be using it) and my hunch is slow startup is more often the app’s fault. Although `from gi.repository import Gtk` seems suspiciously slow… which makes me want to hunt for low-hanging fruit where improvements could be made.
Anyway, let’s do this! Considering how crazy fast computers are these days, I think a 250ms budget for a *warm* startup is generous. Might as well dream big :^)
September 16th, 2011 at 16:07
Optimizing application launch for spinning disks systems is akin to optimizing the GUI for 8 bit graphic cards. We’re moving away from those old dinosaurs. Yes, they’ll stick around for bulk storage for a long time but we’re talking applications here.
As for jumping layouts, I find most program layouts to be fairly static with regard to their data. It is not too distracting to have a list of songs pop into existence when it does at a pre-allocated area of a music player. The problem is that I cannot use the player before the list is shown so it needs to take preference over the cover art and the song lyrics. What I’m aiming for is a prioritized list of todo’s when an application starts, preferably something that can run in parallel.
Unfortunately that might not be enough. IntelliJ Idea has background indexing, resource resolving etc. and even though it is possible for me to start typing fairly quickly after opening a project, the knowledge of the not-yet-ready state of the program holds me back. It might just be the OCD speaking though…