Open
Bug 523429
Opened 15 years ago
Updated 2 years ago
Too much fastload checksuming hurts startup
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
NEW
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?
Reporter | ||
Updated•15 years ago
|
Whiteboard: [ts]
Reporter | ||
Comment 1•15 years ago
|
||
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.
Comment 2•15 years ago
|
||
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
Reporter | ||
Comment 3•15 years ago
|
||
(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
Reporter | ||
Comment 4•15 years ago
|
||
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.
Updated•15 years ago
|
Priority: -- → P2
Comment 5•14 years ago
|
||
Is 1 - 2% on desktop significant enough to make this a high priority for beta?
Reporter | ||
Comment 6•14 years ago
|
||
(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.
Comment 7•12 years ago
|
||
Fastload is now gone, startupcache doesn't quite have this problem.
Comment 8•6 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•