Closed Bug 1612728 Opened 6 years ago Closed 6 years ago

Disable startup cache in SeaMonkey 2.53 and 2.57 build config.

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(seamonkey2.49esr unaffected, seamonkey2.53 fixed, seamonkey2.57esr? affected)

RESOLVED FIXED
Tracking Status
seamonkey2.49esr --- unaffected
seamonkey2.53 --- fixed
seamonkey2.57esr ? affected

People

(Reporter: frg, Assigned: frg)

References

Details

(Whiteboard: SM2.53.1)

Attachments

(3 files)

The startup cache causes problems with enabling and disabling extensions and themes in 2.53.1 and up. Initial findings suggest that any performance gain here is neglectable so it should be disabled by default.
This can be done by providing --disable-startupcache as an option in the mozconfig file but we probably want it by default so that distributions don't need to do it too.

See:
Bug 1444957
Bug 1484393
http://forums.mozillazine.org/viewtopic.php?f=6&t=3058711&p=14856248#p14856248

For our 2.53 and 2.57 gitlab release branches only. Extensions are more or less gone after 2.57 so not needed for central.

[Approval Request Comment]
Regression caused by (bug #): various.
User impact if declined: Updated/disabled themes or extensions might need to be installed a few times until they work.
Testing completed (on m-c, etc.): 2.57
Risk to taking this patch (and alternatives if risky): There might be a minor startup performance loss on older slower systems.
String changes made by this patch: --

Attachment #9123951 - Flags: review?(iann_bugzilla)
Attachment #9123951 - Flags: approval-comm-release?
Attachment #9123951 - Flags: approval-comm-esr60?
Comment on attachment 9123951 [details] [diff] [review] 1612728-startupcache-253.patch [Triage Comment] LGTM r/a=me
Attachment #9123951 - Flags: review?(iann_bugzilla)
Attachment #9123951 - Flags: review+
Attachment #9123951 - Flags: approval-comm-release?
Attachment #9123951 - Flags: approval-comm-release+
Attachment #9123951 - Flags: approval-comm-esr60?
Attachment #9123951 - Flags: approval-comm-esr60+

(In reply to Frank-Rainer Grahl (:frg) from comment #0)

Initial findings suggest that any performance gain here is neglectable

Are there any test results? (cpu, HD/SDD etc.)
I'm worry a bit since starting with "-purgecaches" increases startup time for me up to 30% (1.25s --> 1.60s) .

(In reply to Frank-Rainer Grahl (:frg) from comment #1)

Risk to taking this patch (and alternatives if risky): There might be a minor startup performance loss on older slower systems.

Considering the "target audience" of SM, it seems likely enough that many of them still use old systems. Not because of no money, but because of the same habits because of which they use SM...

FF continues to support startupcache (fe. bug #1550108 for FF71), it seems there are reasons for it even in the modern World.

Since at the Linux downstream level we have own startup shell script, is it possible to pre-determine the problem situation by it and use "-purgecaches" then? I mean something like dir/file modify timestamps in some "extensions" locations etc.

Are there any test results? (cpu, HD/SDD etc.)
I'm worry a bit since starting with "-purgecaches" increases startup time for me up to 30% (1.25s --> 1.60s) .

purgecaches does a lot more. xul cache and others. I really don't see/notice any difference with my old 10 year old thinkpad and a HDD. Maybe if you have lots and lots of add-ons which load at startup.

Considering the "target audience" of SM, it seems likely enough that many of them still use old systems. Not because of no money, but because of the same habits because of which they use SM...

Anything below a 1.8GHz Core2Duo and 4 GB is self torture and should not be rewarded :)

Lets see how it goes. We could always back it out in a future release if it really causes trouble. I doubt it.

FRG

Well, about 10-15% increase of startup time (i7-3520M CPU @ 2.90GHz, 8Gb, HDD, Linux CentOS-7).

It could be an acceptable solution to speed up 2.53.1 release, but in the long run it is a big enough cost not to create a more accurate patch.

I'll try to see what can be done instead.
Because I am usually in a rage when a new version of a large program starts slower than the old one. Even by 10%. :)

Is this a comparison on startup time between 2.49.5 and2.53.1 or a comparison of 2.53.1 with and without the startup cache?

Surely between 2.53.1 with and without startup cache.

(2.49.5 is about 30% slower than 2.53.1+cache)

(In reply to Dmitry Butskoy from comment #7)

Surely between 2.53.1 with and without startup cache.

(2.49.5 is about 30% slower than 2.53.1+cache)

Just making sure Iw
sonder what is different in others experience they cannot see any difference. a 10% slowdown one would think should be perceivable.

Flags: needinfo?(iann_bugzilla)

Are there any reproduceable cases, or at least some more still active reports?
Cannot reproduce, thus cannot participate here. Looks like "closed worksforme' case... :/

Considering how --disable-startupcache work, it just define MOZ_DISABLE_STARTUP_CACHE macro, which is present in only one code fragment:
https://hg.mozilla.org/releases/mozilla-release/file/d4134557db7c/startupcache/StartupCache.cpp#l84

#ifdef MOZ_DISABLE_STARTUPCACHE
    return nullptr;
#else
    StartupCache::InitSingleton();
#endif

IOW, all the code remains compiled anyway. It looks like a runtime-checked preference is much more suitable here.

We can help people with such hard-reproduceable issues by providing something in Preferences-->Advanced-->Cache :

  • either a checkbox toggling new startupcache preference;
  • or just a button "Clear startup cache";
  • or both.

What variant to choose from? (Then I'll try to provide a patch).

Flags: needinfo?(iann_bugzilla) → needinfo?(frgrahl)

Sorry we are a bit busy with the 2.53.1 release. Personally I would not invest any time in this. I see no notable startup difference with or without even on a 9 year old laptop. Even wth only a HD I fail to see any notable improvement. Not sure if this changes if you have tons of add-on but unless users start to complain I would just keep it this way. The patch only flips the default so if someone needs it it can still be compiled in.

Flags: needinfo?(frgrahl)

Just let it be here for possible future needs.

Use environment variable MOZ_DISABLE_STARTUPCACHE instead of macro. Thus the same compiled code behaves differently. (It seems "too early" and unreliable to use prefs here, OTOH env vars already used there anyway).

Could be useful for testers etc. who update addons too often.

Adds new button to Preferences-->Advanced-->Cache :

--Startup Cache------------
-  Startup cache is used to speed up SeaMonkey loading. (Updates or changes of some addons
-  and extensions might require to flush the cache afterwards.)
-  [ Clear startupCache ]
-----------------------------

The button calls "Services.appinfo.invalidateCachesOnRestart()", which just adds the line "InvalidateCaches=1" to compatibility.ini to clear caches after next (re)start.

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: SM2.53.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: