Thinking about "Slowness at Startup"

I am recording these episodes of "Slowness at Startup" mainly to record hard data as to how real this problem is.

Partly because one day I was talking with Linus - at the approximately once a year dinner David Kanter arranges for Portland area folk - and I said, in passng "I hate opening my laptop, it always takes 5 minutes to come out of standby". Linus looked at me witheringly, partly with the "You stupid fool, you shouldn't be running Windows" attitude he always wears, but also disbelievingly because he said that "even Windows" came back from standby quicker than this.

Partly because I work with people who claim that they are responsible for Windows coming out of standby in 30 seconds or less, 15 seconds, etc. - and who say that they are going to get it to just a few seconds.

There is a major mismatch between what these guys claim, and what I experience.


I suspect that a lot of the mismatch lies in how you measure time to "Get out of standby".

I think that many of them measure it as "time to see the screen redrawn". Whereas I measure it as "time to actually being able to use my computer to get work done." For example "time for me to read the first email in my Outlook Inbox", which is fairly unambiguous, although it does depend on Outlook's state when I went into standby.

"Time to read Outlook email" is my main metric, although I have others, such as "Time to being able to use a web browser to do a Google search". Or "Time to my screen being resized to take advantage of the two monitors I have when docked, or to fot onto my laptop screen when undocked". (This can be critical, because it is pretty close to impossible to work when you have a large screen displayed on a small monitor, but, unfortunately, often the applications come up quickly but the screen resizing (Thinkpad Presentation Director) takes a lot longer. Not to mention that resizing my screen often takes 2-3 minutes in and of itself.

It has been a truism that one should design systems to get the screen drawn quickly, even though the application is not yet ready to do so. I am not so sure that this is a good idea any more - I find it quite irritating that a window is up, doing nothing, while the application is ever so slowly coming back to life. I find it hard to tell the difference between an app that is coming back slowly, and one that is dead. I probably waste a lot of time killing such apps, and restarting.

I think that it might be better user interface design to make it explicit what is happening to app.

Instead of

(0) Window manager draws a frame, but the window contents is blank
(delay of a few minutes)
(1) Application receives a redraw event, redraws the window contents, but isn't ready to respond to keyclicks
(delay of a few minutes)
(2) Application is finally responsive

with no visual difference between (1) and (2), except maybe for the hourglass cursor, which isn't reliably displayed, how about:

(0) Window manager draws a frame.
Window manager redraws the window contents from backing store.
Window manager greys or shades the window, to indicate that the app is not ready yet
(1) OS doesn't even allow the application to do anything until its working set is loaded
(delay of a few minutes)
(2) Application working set (from before the standby) is loaded, app can be expected to be responsive.

This gets you to the place where you can see the window contents quickly, quicker than Windows does now. You can flip through apps, or, if you are like me and often have your calendar up, look at an old display of your calendar, which may have the info you need.

But it delays making the application appear to be ready to talk to you, until it truly is. Thus diminishing that frustrating "I don't know if the application is ready or not" delay that trakes 5 or more minutes on my current system.

For extra credit, ungrey buttons as the application is ready to deal with them. For example, ungrey the close window / kill application button as soon as possible, but only ungrey resize when thre application is ready.

---

I'm not going to say "It's not the slowness, it's the user interface that makes the slowness more frustrating". Because the slowness is a problem.

But the user interface is particularly annoying, and exacerbates the slowness.