517956 - Too much junk in fastload files

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Brendan Eich [:brendan]]

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

Comment 3

[Brendan Eich [:brendan]]

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

/be

Comment 4

[Dietrich Ayala (:dietrich)]

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

Comment 5

[(dormant account)]

Filed this bug due to misunderstanding how fasl works.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Brendan Eich [:brendan]]

(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

Comment 8

[Brendan Eich [:brendan]]

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

/be

Comment 9

[Brendan Eich [:brendan]]

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

/be

Comment 10

[(dormant account)]

(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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 12

[(dormant account)]

(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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmm...  I was starting it the same way with and without my patch....

But maybe I mismeasured something after all.

Comment 14

[(dormant account)]

(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.