I think my current performance pet peeve is shutdown. Assorted flavors of it, they all seem to have the same kind of problem. Sometimes we’re stuck with it… but maybe we shouldn’t be?
This is one time when our basic training, which normally I love so much, tends to let us down. We were all taught to clean up our own messes — programming wise that means freeing your resources after you are done with them. But this backfires in the shutdown case.
Many times I watch as I hit the [X] close button on some application and my poor computer starts to swap as the application goes about paging in vast amounts of its code and then dutifully walking all its data structures– more paging — and giving them back to the operating system. My reaction to this in a word: ACK!!!!
When your application is ordered to shutdown the last thing you should do is enumerate every piece of memory you have ever allocated and systematically give them back to the operating system. Your program has a death sentence, and soon your resources are going back to the operating system whether you like it or not: what you must do is look at the minimum possible amount of memory necessary to get to a nice safe stable state and then exit as quickly as possible. Abandoning your memory like this gives the operating system the best chance to get your process unloaded while swapping in the least amount of memory and causing the least impact to the systems disk and memory caches.
In short, shutdown is no time for spring cleaning.
And why all this cleaning anyway? Many people report that they have all these important resources that need flushing and so forth. They couldn’t possibly get to a safe state without considerable work but usually that in itself is symptomatic of assorted problems. Any application that has important data to manage almost certainly needs to be tolerant of power-failure and if that’s the case when the user makes important edits they likely should be automatically saved to a durable location. In fact at any given moment, probably only a few seconds worth of data should be at risk. If your application has been idle for any length of time it should be fully saved — and even if the user hasn’t chosen to save their work it’s still effectively saved somewhere so that you could restore in the current “dirty” state.
So if you have to do all this work to be resilient to power failures, then take advantage of that logic to simplify your shutdown paths. Your users will thank you.