Comments on: Startup: Backward Constructors

By: Miguel

Miguel — Fri, 18 Jun 2010 14:08:27 +0000

That Michael Meeks has a sharp eye.

By: Stu

Stu — Fri, 18 Jun 2010 13:29:37 +0000

Patching GCC sounds like a great idea… if constructors are run forward then surely this could help any programme compiled in this way.

By: TheFutureIsNear

TheFutureIsNear — Fri, 18 Jun 2010 12:47:53 +0000

If Firefox cannot improve its startup speed then it will die

By: Osiris

Osiris — Thu, 10 Jun 2010 18:15:47 +0000

Not to be trolling, but after reading several posts in this blog i get the impression that this work – while certainly interesting and insightful – is attacking the wrong problems with firefox/mozilla.

For example firefox’s current caching implementation is so horrible that its performance impact on startup times is orders of magnitude greater than any library load ordering, assuming you’re reloading tabs. [disk cache is restricted to 8192 items and has a hashing algorithm with lots of collisions, evicting valid items => open 100 tabs with 10 files each, restart FF, see a slow reload-fest]

By: glandium

glandium — Sat, 29 May 2010 08:52:57 +0000

FWIW, the cycle collection induced static initializers are just initializing vtables…

By: tglek

tglek — Fri, 28 May 2010 21:25:21 +0000

I tried modding the compiler to do the equivalent of __attribute__ ((section (“.text.initializers”)));, but basically every constructor, generated func, etc must be tagged correctly. That’s a decent chunk of work to do right, so I decided to leave that as an exercise for the reader.

Most of the ones I checked were cyclecollector stuff. It would be an interesting project to make logging/cyclecollection initialize lazily. Thanks for identifying logging as a problem too.

ld doesn’t do any linktime optimization. gcc 4.5 lto is too buggy to even bother with atm. It would be nice to engage llvm folks on this, perhaps someone there will want to make application startup competitive.

By: glandium

glandium — Fri, 28 May 2010 12:12:05 +0000

I heard the llvm linker now does more link-time optimizations than GNU ld, maybe it would be worth checking it out, too.

By: glandium

glandium — Fri, 28 May 2010 10:41:32 +0000

So, it turns out only a few are PR_NewLogModules.
Most are actually due to cycle collection (from which a great number happens in SVG code, which is pretty much pointless at startup), some others are due to statically initialized instances of some classes that look like singletons, some others only contain a “ret” instructions (in which case one can wonder why gcc emits them), some others are due to the use of iostreams (in chromium code), a few are html5 parser initialization of static data,

Most of these constructors actually don’t do much, only copying data around, not even calling functions. Some do call functions, though.

Anyways, unfortunately, the __attribute__((section)) thing can’t work with these static initializations…

By: glandium

glandium — Fri, 28 May 2010 09:52:13 +0000

I did some little investigation which got me interesting data: while I didn’t check all these constructor functions, all that I checked are due to constructs like this in the source:
static PRLogModuleInfo *gWordCacheLog = PR_NewLogModule(“wordCache”);

(yes, all of those I checked were calls to PR_NewLogModule)

By: glandium

glandium — Fri, 28 May 2010 08:35:32 +0000

> An interesting optimization would to have the compiler transitively mark functions reached by library initialization and place those in a .text.initializers section.

You can try __attribute__ ((section (“.text.initializers”)));