Startup

From APIDesign

Current revision

First impressions are very hard to change. This old observation is valid in many fields of human behavior. It is also valid in software development. The first impression can be decisive. Make sure your programs behave so that users don't think: ooh, so broken, or ooh, so slow.

In the case of desktop applications, executed on users' own computers, one of the first impressiond is the time it takes to launch the application. Especially in case of Java applications this may be significant - it takes time to load all the class files, link them together, recompile them so the HotSpot machine understands them. This can be multiplied by two things: modular applications composed from many individual JARs are going to require more actions during start compared to monolithic applications packaged in one JAR. Second: if the operating system I/O caches are empty (e.g. after boot or wake up from hibernation), each additional I/O (like dealing with one more JAR) is going to have significant effect.

Based on the previous observations we can classify startups into various categories.

Restart

User shutdowns the Java application and starts it again. Well, in this case the effect of I/O operations is going to be minimal. Most of the application libraries, including the HotSpot runtime, etc. has already been loaded in the operating system I/O caches and accessing those files again reduces to memory only access. That is fast. Much faster than any I/O.

Performance point of view conclusion: Don't pay attention to this case, it is fast enough by itself.

Post-install Initial Launch

In fact the first application startup is not the first user experience. Before that the application needs to be installed. Obviously, the installation needs to be smooth (but that is a topic for another analysis), however it does not have to be fast. Case studies show that users are used to wait for installation to finish and are ready to accept if it takes some time (there is a rummor that Apple, the leading innovator in user interface design, does disk de-fragmentation as part of install of any application; disk de-fragmentation is completely independent task, yet doing it as part of installation is more acceptable for users than running it once per 27 reboots of their computer).

Conclusion #1: Installation is a good time to perform various post-installation optimizations.

Most of the (single computer) users that download your application are likely to execute it immediatelly after it has been installed. What effect this has on I/O caches? Well, as the installation writes down almost all necessary libraries and JARs, they are likely to be cached in operating system I/O caches. Reading them again is going to be as fast as doing restart (as described above).

Conclusion #2: From performance perspective, there is nothing to optimize in this case. It is going to fast. Just make sure you are not slowing down this kind of startup by optimizing for other kinds (as described next).

Morning Launch

There are two kinds of desktop applications. Major and minor. A minor application is the one that the user launches, performs some operation and exits. An example of this kind is calculator. A major application on the other hand is started by the user as soon as the computer is started and it remains on until the computer is powered down. Email client, NetBeans (and any other) IDE, or often a web browser falls into this category.

Lauching minor applications is very similar to the above described restart case. Most of the libraries are cached, the I/O load is not heavy, moreover such applications are likely small. Usually performance is not an issue.

Major applications are often large and are executed soon after boot, so the I/O access is significant. Some users are forgiving slow launch of their major applications, however as this is the daily initial experience, it is better to make it as pleasant as possible.

Our experience with NetBeans IDE shows that the I/O disk access was really significant factor in ~1min startup time of NetBeans IDE 6.0. When we addressed it by using single file start caches, we managed to get to ~20s after few releases. Such time is definitely much more acceptable than original one.

Performance point of view: This is the most important usecase. Most of the people do this daily and this is their initial daily experience. Optimize for this.

Hint: There is a way to drop filesystem caches without restart on Linux:

$ echo 3 > /proc/sys/vm/drop_caches

Multi User Initial Launch

First deviation from the most common workflow is multi user setup. One administrator install your application and then many users are going to use it. Only the administrator is going to have the pleasure of post-install initial lauch (if at all), every other user is out of luck. For them, the first start happens after booting computer, without any special setup made before that.

Performance dilema: Optimize for this case or not? NetBeans:Performance team has given up on this usecase in a hope that this happens just once (not every morning) and only in multiuser setups (which is not a majority).

Configuration Change

One of the most common optimizations is to persist the previous state and reuse it during subsequent startup. It is great if reusable caches are created, but only the assumption that they are reusable in subsequent launches. If minor configuration changes like changing own role, policy or mode requires caches to be flushed away, then they may become uneffective.

Performance conclusion: Make sure significant configuration changes are rare.