Some more about the progressive decompression experiment

There are a few things I forgot to mention in my previous post about the progressive decompression experiment, so here they are.

Implicit section grouping

As I mentioned, GCC may now generate function sections with names starting with .text.hot., .text.unlikely., etc. It also expects the linker to group each category together. GNU ld does it, but Gold doesn't, yet.

While grouping these can be interesting for runtime performance, it can also go against startup performance, or only go half-way.

The .text.unlikely. sections being grouped together means that code that is not unlikely will be grouped together, which helps reducing cache pressure at runtime. But something unlikely to be called is not something that is never called, and a lot of unlikely functions are being called during startup. Fortunately, GNU ld places them first.

The .text.startup. sections being grouped together means that static initializers are all stacked together. This is good, because it helps a lot with the awful I/O patterns that can be observed during startup without this grouping. But it only goes half-way because functions that are being called by these static initializers (think class constructors, for example), are not marked as .text.startup. and can still be placed anywhere.

Profiling the right thing

Like with hardware-specific code paths, there are various code paths that can be triggered at startup during the profiling phase that may or may not be triggered in real case scenarios. Having or not having a pre-existing profile, having or not having extensions installed, opening the default home page or opening an url, etc. all have an impact on what specific code paths are exercised during startup.

Anything that happens on actual use cases that weren't part of the profiling scenario may call code that was not covered by any reordering, and go against the startup time improvements progressive decompression can get us. This is why, more than any kind of binary layout tweaks, being able to uncompress any random part of the binary at any time is critical to bring startup improvements to everyone, in every cases.

2011-11-02 08:46:10+0900

p.m.o

You can leave a response, or trackback from your own site.

Leave a Reply