Re: "Hazy watercolor memories... Of..."
If you profile the start-up of a "modern" application. What you find is 3 things generally dominate the profile:
1) Loading from disk. The application has got bigger by orders of magnitude, partly because of code bloat, but mainly because of graphics and other shinies. Your Amiga had a tiny resolution screen in comparison to people running stuff on 4k monitors that have to scale.
2) Memory copies. Oh my god. Don't get me started here. I write high performance applications for a living, and think carefully about every memory copy. But if you follow the memory copies that occur in a "modern" application they are depressing. Pull something off disk into a temporary buffer; copy it into another location whilst you figure out how to use it; clone it 3 times into new locations, most of which die. And on top of that you have garbage collectors that are designed to run during the stable state of the application where everything is neatly divided into long-lived objects and short-life transient objects. But at program start-up you don't know which is which, so the GC often ends up copying objects that will become long lived multiple times until it figures out that the object is going to last through the lifetime of the app.
3) Pointless UI hooks. This one isn't quite as big, but a modern GUI has a shed tonne of UI hooks. Not just your basic "OnClick" but also UI hooks for when something is loaded, when it is rendered, when something is rendered on top of it, when the mouse moves over it, etc. A modern OS might easily have 50-100 UI hooks for every UI element. All these get called multiple times during start-up. Even if no code is implemented in the hook, due to the virtual implementation of these hooks, they often have to be called to figure that out. Especially in dynamic or JIT compiled languages.
It could all be improved. I've seen number 3 fixed by disabling all UI hooks during start-up - but that isn't always possible in every GUI framework. Number 1 has improved more recently by throwing SSD at it. There are some system level things you can do for number 2 (improved GC for example). But in general, it is down to the app writers. Lazy loading of objects from disk that you don't need for initial start-up, or reduced memory copies in your app, are both things that the app writer has to figure out. Unfortunately, like installers, it isn't irritating enough to the app developer to actually bother to fix. (If you have just waited half an hour for a compile to run, or a regression test suite to run, how is 10s to start the app going to bother you).
Biting the hand that feeds IT
