JS atoms are flattened (this is really a JS XDR bug/misfeature) into strings as they are serialized. URI specs and file pathnames are not compressed if relative to an earlier base. Etc. /be

Following bug 107907 to 0.9.7. /be

Design note to self: JS XDR is a lower below the object/binary stream implemented by nsFastLoadFile{Reader,Writer}. Both layers want a dictionary of shared strings (for strings long enough to be worth sharing). A new interface, nsIFastLoadStringTable (or perhaps a more generic name), should be implemented and used by nsFastLoadFileWriter::WriteString, etc. /be

This one is following bug 107907 to 0.9.8. /be

Still want this for 1.0, which means 0.9.9 or bust. /be

Bust. This is not vital for 1.0 unless someone can show a big startup perf gain over what FastLoad currently gives. The file (not RAM, except for the extra i/o) footprint doesn't matter enough to rush this in. /be

I'm an optimist. /be

This is 1.2alpha material, not 1.1beta. /be

Moving out, some of these may move to 1.3alpha shortly. /be

Fixing TM. /be

This should be a feature in the rewamped startup cache.

Comment 10 and the dependency on bug 520309 say that this bug must wait, but see bug 517956 comment 2 for reference to bz's specific script->filename issue, which could be fixed ad-hoc. /be

Ben, feel free to steal or dup. /be

I guess this is a sort of metabug now? I have patches in bug 518230 and bug 632253 which reduce the size of serialized scripts a bunch. XPIProvider.jsm is 40% smaller with those patches. However, the serialized js is still bigger than the original js when compressed.

Is this a problem specific to XDR? Does this even still exist with s/fastload/startupcache/?

(In reply to Benjamin Smedberg [:bsmedberg] from comment #14) > Is this a problem specific to XDR? Does this even still exist with > s/fastload/startupcache/? yes see comment 13