Closed Bug 635838 Opened 13 years ago Closed 13 years ago

Consider backporting to Camino 2.1 some pref changes made between Gecko 1.9.x and 2.0.x

Categories

(Camino Graveyard :: Preferences, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cpeterson, Assigned: cpeterson)

Details

Attachments

(1 file, 1 obsolete file)

Here are some FF4 optimizations that are simple pref changes that may be easy backport to Camino. I assume these changes were not backported to FF3.6 because they are optimizations, not just bug fixes. I found these when diffing FF3.6's and FF4's "modules/libpref/src/init/all.js" files. Setting this prefs in all-camino.js overrides Gecko's all.js defaults.


1. network.buffer.cache.size increased from 4KB to 32KB with bug 545334 (4k size buffer is very small and makes page loading/files downloading noticeable slower).

2. media.cache_size increased from 50MB to 500MB with bug 572235 (Increase default media cache size from 50MB to 500MB).

3. network.http.accept-encoding tweaked to improve compatibility with upstream cache servers with bug 576033 (Accept-Encoding syntax causes upstream cache inefficiency).

4. browser.cache.disk.capacity increased from 50MB to 250MB with bug 193911 (Increase default disk cache size).

The effectiveness of #4 would be limited by the disk cache's 8192 entry limit (fixed in FF4 by Bug 175600) and a poor hash function (fixed in FF4 by Bug 290032). In my casual testing with just these pref changes, Camino's about:cache stats hover around ~7000 entries and ~80MB storage. Perhaps increasing Camino's disk cache to ~100MB (instead of 250MB) might be a reasonable compromise until Camino gets Gecko 2.0's other cache fixes.
Attached patch backported-prefs-v1.patch (obsolete) — Splinter Review
Attachment #514145 - Flags: review?(alqahira)
Comment on attachment 514145 [details] [diff] [review]
backported-prefs-v1.patch

(In reply to comment #0)
> 1. network.buffer.cache.size increased from 4KB to 32KB with bug 545334 (4k
> size buffer is very small and makes page loading/files downloading noticeable
> slower).

This seems fine, given mfinkle wanted it for Fennec (although they ended up doing only 16KB, not 32KB, and still use the former in preference to the Gecko 2 default) and got the underlying code change landed on 1.9.2.  Have you done any sort of testing of this with Camino?

> 2. media.cache_size increased from 50MB to 500MB with bug 572235 (Increase
> default media cache size from 50MB to 500MB).

I'm worried about this because 1.9.2 doesn't have any memory-pressure notifications (IIRC) and because of bug 572235 comment 1 (delaying the start of playback even longer, and because 1.9.2 doesn't have the HTMLMediaElement.buffered attribute which would work around that).

> 3. network.http.accept-encoding tweaked to improve compatibility with upstream
> cache servers with bug 576033 (Accept-Encoding syntax causes upstream cache
> inefficiency).

Yay!

> 4. browser.cache.disk.capacity increased from 50MB to 250MB with bug 193911
> (Increase default disk cache size).
> 
> The effectiveness of #4 would be limited by the disk cache's 8192 entry limit
> (fixed in FF4 by Bug 175600) and a poor hash function (fixed in FF4 by Bug
> 290032). In my casual testing with just these pref changes, Camino's
> about:cache stats hover around ~7000 entries and ~80MB storage. Perhaps
> increasing Camino's disk cache to ~100MB (instead of 250MB) might be a
> reasonable compromise until Camino gets Gecko 2.0's other cache fixes.

I'm really concerned about the old 64MB breaking disk cache entirely problem (see bug 569709 comment 38 and bug 443067; nothing is ever cached!) that wasn't fixed until Gecko 2; even increasing to 100 MB would trigger that, it seems.  I'm curious as to why your results are different.

So, I'm fine with the buffer change (some idea of what sort of results were expected, besides "faster", would be nice) and the accept-encoding change, but I don't think we should take the other changes, because they seem much more dependent on other code changes for good/better/working behavior, and those code changes aren't on 1.9.2.
Attachment #514145 - Flags: review?(alqahira) → review-
> This seems fine, given mfinkle wanted it for Fennec (although they ended up
> doing only 16KB, not 32KB, and still use the former in preference to the Gecko
> 2 default) and got the underlying code change landed on 1.9.2.

Bug 545334's early patches used 16KB, but the trunk commit used 32KB. Or is Fennec in a separate repo?

http://hg.mozilla.org/mozilla-central/rev/a8c70cdbf50b

> I'm fine with the buffer change (some idea of what sort of results were
> expected, besides "faster", would be nice)

Do you recommend any particular browser tests? Do Mozilla's Talos/tp4 tests work for Camino? 

> I don't think we should take the other changes, because they seem much more
> dependent on other code changes for good/better/working behavior, and those
> code changes aren't on 1.9.2.

Given the concerns listed in the other bugs, that sounds like a good idea. I can post a new patch soon.
(In reply to comment #3)
> > This seems fine, given mfinkle wanted it for Fennec (although they ended up
> > doing only 16KB, not 32KB, and still use the former in preference to the Gecko
> > 2 default) and got the underlying code change landed on 1.9.2.
> 
> Bug 545334's early patches used 16KB, but the trunk commit used 32KB. Or is
> Fennec in a separate repo?
> 
> http://hg.mozilla.org/mozilla-central/rev/a8c70cdbf50b

Fennec's in mobile-browser and releases/mobile-1.1: http://hg.mozilla.org/mobile-browser/annotate/d51ca6d7732a/app/mobile.js#l129 / http://hg.mozilla.org/releases/mobile-1.1/annotate/b28b396278b1/app/mobile.js#l470

> > I'm fine with the buffer change (some idea of what sort of results were
> > expected, besides "faster", would be nice)
> 
> Do you recommend any particular browser tests? Do Mozilla's Talos/tp4 tests
> work for Camino?

Ordinarily I would have suggested the Tp test we used to run on our Tinderboxen, but we lost our copy of the pageset, and it wasn't supposed to be public, anyway.

It's highly unlikely that any of Talos will work with Camino.  However, you could probably grab the standalone Talos archive (https://wiki.mozilla.org/StandaloneTalos#How_to_set_up_Talos_for_testing_at_home item #4) and get the old Tp2 pageload test (http://localhost/page_load_test/framecycler.html) to run by editing parray.js to match the pageset that's shipped in standalone Talos (page_load_test/pages/).  Not sure if it prints a nice simple single-number end result like Tp used to do, or just lots of per-page values.

For that matter, you could create your own pageset based on the top N Alexa sites (http://www.alexa.com/topsites) and use the Tp2 framecycler to test them, either over the network or from localhost (saving them as HTML Complete).

(I've wanted to get us running a sane Tp test again for about 3 years, but I've never had the time.)
I ran the Tp2 framecycler tests (from localhost on my MBP), but the results varied. I created a new profile before each browser test. Below are the mean times to run through Tp2 framecycler's 29 local pages. (Multiple test runs separated by semicolons.)

Camino was clearly the slowest browser. Increasing Camino's network.buffer.cache.size generally reduced the test times and variance between runs.

* Camino 2.0 = 21557 ms
* Camino 2.1a1 4KB (FF3.6 size) = 27942 ms; 19500 ms
* Camino 2.1a1 8KB = 28379 ms
* Camino 2.1a1 16KB (Fennec size) = 20756 ms; 14754 ms
* Camino 2.1a1 32KB (FF4 size) = 20600 ms; 19945 ms; 16409 ms
* Firefox 3.6 = 14461 ms
* Firefox 4.0 = 10606 ms; 16010 ms
* Safari 5 = 12147 ms
* Chrome 11 = 11112 ms

Any thoughts on why Camino would be so much slower than Firefox? I tested Camino 2.1a1's official build, not a local build. Given these results, it seems increasing Camino's network.buffer.cache.size "couldn't hurt", but is overshadowed by some bigger perf problem.
:O That's really a Stuart-level question.  I can't believe it takes us 1.5x-2x as long as Firefox 3.6.x; embedding typically used to provide less overhead, making us faster :-(
Patch v2 only overrides Camino's network.buffer.cache.size and network.http.accept-encoding prefs.
Attachment #514145 - Attachment is obsolete: true
Attachment #515428 - Flags: review?(alqahira)
Comment on attachment 515428 [details] [diff] [review]
backported-prefs-v2.patch

r=ardissone
Attachment #515428 - Flags: superreview?(stuart.morgan+bugzilla)
Attachment #515428 - Flags: review?(alqahira)
Attachment #515428 - Flags: review+
Comment on attachment 515428 [details] [diff] [review]
backported-prefs-v2.patch

sr=smorgan

Thanks for finding and testing these!

(I have no idea offhand what's up with our numbers in your testing, unfortunately.)
Attachment #515428 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
http://hg.mozilla.org/camino/rev/7221357ed20b
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I wonder if our specification of "--enable-optimize" in the mozconfig is somehow affecting the module optimizations where it didn't (as of 1.9.0) used to do so?  At some time between Gecko 1.9.0 and Gecko 1.9.1, that vanished from Firefox mozconfigs; I can't find any reference to when/where/why given the repo switch for those things :/

Another item of speculation might be that they're doing something fancy optimization-wise with libxul that doesn't happen with a normal static application; at least when libxul was first turned on for Firefox/Mac, though, it was a pretty substantial perf hit.

The former should be fairly easy for someone with some time to test by doing with/without builds; http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/tools/tinderbox-configs/camino/macosx/cb-xserve04/mozconfig&rev=CAMINO_2_1_M1_9_2_BRANCH is the official nightly/release mozconfig for 2.1.
Comparing a build (10.4sdk / gcc 4 / intel only) with "--enable-optimize" removed from the mozconfig to the official 0322 nightly build.

Ran through Sunspider, Dromaeo and Google's V8 test suite.

Basically results are equal, no better, no worse.

Sunspider (best of 5): http://dev.l-c-n.com/camino/g19x/sunspider.txt
V8: http://dev.l-c-n.com/camino/g19x/v8-testsuite.txt
Dromaeo (03-22 is the right column): http://dromaeo.com/?id=134960,134954


Chris Peterson - do you still have Tp2 framecycler tests ? Can you try it again ? Otherwise, I'll look into installing it on my machine - over the WE probably.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: