I wasn't happy with startup times on my OS X dev machine last week, so I spent some more time looking at it. Startup speed with ~500 files open was about 450ms, which is just enough to feel slow.
After some profiling, the culprits were:
- Font rasterisation. When creating fonts, the ASCII glyphs were eagerly cached, allowing faster lookups (array lookup vs hash table lookup for non-ascii glyphs). The faster lookup is important, but the eager glyph creation isn't: for the cost of one well predicted branch, the ASCII glyphs can be lazily generated. This alone saved about 80ms of startup time for my test case.
- Additional laziness during session restore. Moved some work that was being done per-file during session restore to be done once at the end of session restoration. Saved a small amount of time.
- Faster settings lookup. An unexpectedly large amount of time was being spend applying settings to view objects. Firstly, it was being done too frequently, so I reduced that. The next item was that each lookup was triggering a memory allocation, which is a common pitfall of using a std::map in C++ keyed by strings. Fixing that helped a little too.
After the above and a few other things, the test case went from ~450ms to a bit above 300ms. Aside from the font rasterisaion changes, most of the improvements should only be important if you have a large number of files open. Last time I was benchmarking startup times, it was with a much smaller number of open files, and the ASCII glyph lookup optimisation hadn't been implemented.
You should generally see better numbers than 300ms for a warm startup, for example, on my Windows dev machine, which has much less than 500 files open, startup times are around 80ms.