Open Bug 523429 Opened 15 years ago Updated 2 years ago

Too much fastload checksuming hurts startup

Categories

(Core :: XPCOM, defect, P3)

x86
Linux
defect

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ts])

Checksumming consistently shows up on desktop profiles at 1-1.5% of xulrunner startup on my c2d laptop.

I think there are 2 issues.
a) Fastload contains up to 2x more data than is actually needed during startup.

b) We should trust the filesystem more(ie we don't checksum libxul.so/etc) on every startup. So I think we should correlate writes to checksumming. Ie we should only checksum on the first startup post-updating fasl files. Should just flip a pref?
Whiteboard: [ts]
I should mention that a) should be solved by disabling fastload creating during component registration startups.

Doing that will mean that subsequent startups will write the fasl cache in the natural order that files are accessed. Then when bonus components are needed they'll get appended to the tail of fasl where they belong.
Great bug report -- (a) is easy to fix I hope. (b) is a good point too. We did not mistrust (or distrust, warranted compared to mistrust) the filesystem in the old days but we did want to avoid crashing and leaving an incomplete .mfasl file around to cause more grief.

/be
(In reply to comment #2)
> Great bug report -- (a) is easy to fix I hope. (b) is a good point too. We did
> not mistrust (or distrust, warranted compared to mistrust) the filesystem in
> the old days but we did want to avoid crashing and leaving an incomplete .mfasl
> file around to cause more grief.
> 
> /be

so do you think pref-toggling idea would work? or there a better place to put run-count-dependent toggles
I'm not sure what effect this would have on cold startup on desktop. On n810 it's somewhere around 100-150ms that could be saved from this.
Priority: -- → P2
Blocks: 447581
Depends on: 520309
Is 1 - 2% on desktop significant enough to make this a high priority for beta?
(In reply to comment #5)
> Is 1 - 2% on desktop significant enough to make this a high priority for beta?

only if it is an easy win.
Fastload is now gone, startupcache doesn't quite have this problem.
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.