Reading in typelib files takes around 50 milliseconds every startup on my Nexus S. We could instead make the file format look a lot more like how this data is stored in memory.

I think we'd wait on this until remeasuring after the DOM moves off XPConnect, but it might still be worth doing after that.

I thought about this a bit while writing xpt.py. bsmedberg had mentioned a while ago maybe just producing C++ code with structs instead of .xpt files for our built-in typelibs, that could be another option.

How much of that time is I/O and how much is other things? We aren't going to significantly reduce the I/O by rearranging the data, right? And yes, I think we could do this more easily by making XPT output structs and just compile them into libxul without trying to touch the XPT format.

I don't have data on the I/O time vs CPU time. Autogenerating the files sounds like the best route to me though.

At this point, we're more likely to generate structs instead of messing with anything about how the current XPT files are loaded.