Ayende @ Rahien

Refunds available at head office

Why startup times of applications MATTER

imageVery often I see people trading startup performance for overall performance. That is a good approach, generally. But it has huge implications when it gets out of hand.

There is one type of user that pays the startup cost of the system over and over and over again. It is YOU!

The developer is the one that keeps restarting the application, and overly long startup procedure will directly effect the way developers will work with the application.

Not only that, but since startup times can get ridiculous quickly, developers start working around the system to be able to avoid paying the startup costs. I have seen a system that had ~3 minutes startup time. And the developers has moved a lot of the actual application logic outside the system (XML files, mostly) in order to avoid having to start the system.

This is something that you should keep in mind when you trade off overall performance for startup performance. It is usually preferable to either do things in the background, or softly page things in, as demands require it.

This is usually something that require a more complex solution, though.

Comments

pete w
02/13/2009 08:52 PM by
pete w

Ironically, I stumbled upon this while I was waiting for my visual studio to load a project.

Lets think about the mechanics of a large program like VS for a moment. Most of the time is spent loading the bits from disk into memory, this is a physical bottleneck.

My guess is that in a year or two once SSDs become more of a commodity programs like Visual studio will not cause so much frustration. I hope I am right

Chris Smith
02/13/2009 09:00 PM by
Chris Smith

Thank you, thank you, thank you for this post. Yet more proof that I'm not insane (something I need daily at the moment).

I've been arguing fiercely over doing a stop and fix on our startup time. Our app (ironically only when debugging - the critical time) takes around 3 mins to start, mainly loading and validating mapping files and bringing spring up.

"Not a commercial priority" according to management apparently. They want to see "screens delivered" rather than us fixing hampering, frustrating problems...

But... considering 11 developers, 3 minutes, 8 times an hour, 7 hours a day = (8x7x11) = 616 restarts a day = (616*3/60) = 30.8 paid hours a day thrown in the bin. I would say that is more than significant.

Someone save my sanity. Yes you know who you are if you are reading this.

configurator
02/15/2009 02:41 AM by
configurator

Speaking of startup times. I installed the Windows 7 Beta on my laptop a few days ago. When using Vista (with SuperFetch enabled, of course), Visual Studio 2008 took about 30-40 seconds to load.

Now, I can't even measure the time it takes - it's less than a second.

I have no idea how they did that, actually.

Dave
02/16/2009 08:06 AM by
Dave

I use the 'Future' method of the parallels library. Most application have long startup times because they have to initialize a lot of data and services (components) before the application can start.

With Futures you delegate these tasks to the background where it's loaded. When you try to access an object while it not yet loaded, the task gets the highest priority and blocks until the item is loaded.

When the time between starting a display and seeing 'something' takes longer than 2 seconds, PLEASE show something, even if it's only a splashscreen. It tells the user that the application is loading and prevents the user from starting your application multiple times.

Comments have been closed on this topic.