Our run-time linker could measure the time we are spending in constructors.

This measures relocations and constructors timings on startup. The interesting part is that it actually only works for the child process, and reports the following on my nexus s: Spent 3ms on relocations, 15ms on constructors. It should be noted that constructors do include the elfhack initialization, so it also includes relocations. With elfhack disabled, I get: Spent 98ms on relocations, 4ms on constructors Two things to note about this: - elfhack's relocations are much faster than the linker's because it's a tight loop and doesn't need to handle several relocation types. - constructors have a very low overhead on warm startup (child initialization is a warm startup) Now, the reason why this patch only works for the child initialization is that we actually don't use our linker when using the library cache, and use the system linker instead. Which means we don't benefit from all the improvements we've made to our linker. I'll file a separate bug for that. Without library cache (iow, when the libraries are uncompressed on the fly), the timings on the main process look like this: elfhack disabled: Spent 45ms on relocations, 3ms on constructors elfhack enabled: Spent 2ms on relocations, 10ms on constructors It is interesting to see that child process initialization is slower. No idea why at the moment.

With library cache and an experimental fix for bug 686282, this is what I get on cold cache: elfhack disabled: Spent 241ms on relocations, 327ms on constructors elfhack enabled: Spent 30ms on relocations, 349ms on constructors

As long as we don't time for more than one hour worth of cumulated time, it's just safe not to care about usec->sec overflow.

It was good to get timings once, I don't think it's useful to land.