As I noted on irc, this function ends up responsible for flushing most of js XDR to disk, not just principals....

Boris was onto something else over IRC: getting rid of redundant filenames and other strings. Just consolidating script->filename could be done by brute force under JS_XDRScript, for the XUL fastload case at least. More general solution that also wins for shared string literals and identifiers: an interned string table in JSXDR. An interned string table that's global to the fastload file could be done but the JS XDR layer would want to benefit from it too, which would seem to require callbacks from JS to XPCOM fastload code. Probably we should do the JS XDR string table first and see if that wins enough not to care about any remaining string redundancy. Please steal bug 104170 and 195010 from my list. See also bug 107907. /be

Maybe this bug is a dup of bug 104170. Its summary was not describing the problem as comment 1 notes. /be

once mmap is done, need to estimate the win from doing this.

Filed this bug due to misunderstanding how fasl works.

Well, hold on I think we should do the JSScript filename thing, no?

(In reply to comment #6) > Well, hold on I think we should do the JSScript filename thing, no? I think that's really bug 104170 -- or a new bug if you prefer. Agree we want to fix it. I'll comment in 104170 for now. /be

See bug 517956 comment 2 for the specific script->filename issue, which could be fixed ad-hoc. /be

Argh, sorry about that. Bugzilla fools me every time. /be

(In reply to comment #6) > Well, hold on I think we should do the JSScript filename thing, no? it's small fish, might save a KB or two. it wont be measurable on startup. On the other hand doing a proper string table could halve our fastload size.

> it's small fish, might save a KB or two. It saved 50% of the size of my XPC.mfasl, and over 30% of XUL.mfasl when I measured, no?

(In reply to comment #11) > > it's small fish, might save a KB or two. > > It saved 50% of the size of my XPC.mfasl, and over 30% of XUL.mfasl when I > measured, no? I'm not sure about XUL.mfasl. But the reduction in XPC.mfasl was due to compreg not happening, so you were missing 1mb worth of fastloaded files. Took me a while to determine that fasl files vary wildly in size depending on when/how moz is started.

Hmm... I was starting it the same way with and without my patch.... But maybe I mismeasured something after all.

(In reply to comment #13) > Hmm... I was starting it the same way with and without my patch.... > > But maybe I mismeasured something after all. you started out with a full cache created during compreg. Then you deleted it, and the subsequent cache only contained files that were needed to startup.