Tune nursery parameters for the speedometer benchmark

NEW
Unassigned

Status

()

P3
normal
a year ago
11 months ago

People

(Reporter: jonco, Unassigned)

Tracking

({perf})

55 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf:p3])

(Reporter)

Description

a year ago
As suggested by smaug, we should investigate whether we can improve performance on the speedometer benchmark by tuning nursery parameters.
Whiteboard: [qf] → [qf:p1]

Comment 1

a year ago
Currently the nursery is 16MB, or 4MB on smaller devices (B2G and Android) my change to Bug 1380768 will also make this smaller on iOS.  On these smaller devices it may be worth-while increasing the nursery size, they may place less soon-to-die objects in the tenured heap and therefore achieve comparable performance with a smaller tenured heap but larger nursery.

Updated

a year ago
Depends on: 1380768

Comment 2

a year ago
See also 1387950
Assignee: nobody → pbone
Status: NEW → ASSIGNED
(linkifying: bug 1387950)

Comment 4

a year ago
I have been performing some benchmarking and also looking at some profiles for speedmeter.  Based on the profiles I've decided that tuning for nursery size with speedometer is premature.  There is too little allocation rate for the number of major collection events, so adjusting nursery size has very little effect, GC performance is dominated by the frequency that GC is invoked by things other than a full heap.  The GC reasons I encountered are:

  CC_WAITING
  USER_INACTIVE
  FULL_GC_TIMER
  PAGE_HIDE

There were no Nursery collections that weren't associated with a major collection, in other words the nursery was never full.

I then captured another benchmark, this time I kept the browser window focused and moved my mouse around above the window.  The USER_INACTIVE GC events went away and I saw a few minor collections due to the nursery being full.

Before we consider tuning the nursery size for speedometer, I suggest we reduce some of the other major collections.

Generally I think it'd be a good idea to reduce the nursery size.  It takes about 10ms to collect a 4MB nursery on my X1 Carbon (anecdotally, I didn't take multiple mesurements).  That's about the maximum I would want if we want to aim for 60fps.

Jon, we can chat tonight about this, for now I'll needinfo you and Steve so that you can see the comment/discuss if you want.
Flags: needinfo?(sphink)
Flags: needinfo?(jcoppeard)
(One is not supposed to really do anything with the browser when running benchmarks, not even moving mouse.)

FWIW, I think bug 1380778 helped quite a bit on how often we trigger minorGC.
(Reporter)

Comment 6

a year ago
From the comments about it sounds like this is not going to have a big impact for QF.
Flags: needinfo?(jcoppeard)
Whiteboard: [qf:p1] → [qf:p3]

Comment 7

a year ago
Due to bug 1397584 I read the profile incorrectly.  Speedometer is doing plenty of allocation, so I think this is still an open question.  I've removed sfink's needinfo since the discussion above is moot.  We might get a few percent improvment out of it so I'll leave the bug open for now.

I was also curious what rante of values to test. I jacked the limit up to 100,000 KB to see what would happen, Spidermonkey keeps growing the nursery to attempt to improve tenure rates.  However as the nursery gets larger I beleive it stops working as a nursery is intended to (young generation hypothesis) and starts working as a second heap with some different altorithms (bump pointer allocation and such).  This doesn't have much to do with this bug but I wanted to write down this observation somewhere.
Flags: needinfo?(sphink)
Priority: -- → P3

Updated

11 months ago
Assignee: pbone → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.