Closed Bug 1015618 Opened 5 years ago Closed 5 years ago

Consequent performance regression with Map objects in Firefox 31

Categories

(Core :: JavaScript: GC, defect)

31 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla32
Tracking Status
firefox31 - wontfix
firefox32 + verified

People

(Reporter: fayolle-florent, Assigned: terrence)

References

(Blocks 1 open bug)

Details

(Keywords: perf, regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140522105902

Steps to reproduce:

Running the following test:
http://jsperf.com/map-vs-object2

Reveals a performance regression when using Map objects. It was introduced within that range of commits (Nightly of 2014-03-29 - Firefox 31):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa163ff81a3&tochange=4f3443da36a1

Here are the results on my computer:
- with Firefox 30: ~153,000 ops/sec
- with Firefox 32: ~106,000 ops/sec

Florent
The discu
OS: Linux → All
Hardware: x86_64 → All
The discussion related to this bug:
https://github.com/firebug/firebug/commit/3f187d53db29c04172977428a815a1928d723c1d#commitcomment-6211060

Simon Lindholm suggests that it could be the Generational garbage collection.

Florent
Component: Untriaged → JavaScript Engine
Keywords: perf, regression
Product: Firefox → Core
(In reply to fayolle-florent from comment #2)
> Simon Lindholm suggests that it could be the Generational garbage collection.

That does seem quite likely, yes.
Component: JavaScript Engine → JavaScript: GC
Flags: needinfo?(terrence)
Speed up the MapObject and SetObject post-write barriers by only inserting remembered set entries when they are really needed.

Yes, the |inline| and |MOZ_UNLIKELY| are both helpful and both required: they get us a 5-10% speedup on this micro-benchmark when both present, but only a 1-2% speedup individually.
Assignee: nobody → terrence
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8429448 - Flags: review?(jcoppeard)
Flags: needinfo?(terrence)
Comment on attachment 8429448 [details] [diff] [review]
speed_up_MapObject_post_barriers-v0.diff

Review of attachment 8429448 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, that's much better!
Attachment #8429448 - Flags: review?(jcoppeard) → review+
I'm not sure how worthy this would be for uplift to 31: it's a big regression, but only affects a JS feature which is still quite niche.
https://hg.mozilla.org/mozilla-central/rev/ee8f081ebce6
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
This test case is pretty sub-optimal for GGC, so I'm not sure if we will be able to get all the way up to FF30's performance. I had a rather larger regression on this hardware and managed to recover about 80% of the performance. It would be nice to know how the numbers look on your hardware with this patch landed. Should be in the 31 May nightly, if you have the time to check.
Flags: needinfo?(fayolle-florent)
This looks pretty good. Below my results:
- Firefox 32 (Nightly 2014-05-31):
 ** map: ~165,000
 ** obj: ~105,000
 ** obj2: ~120,000
- Firefox 30: 
 ** map: ~151,000
 ** obj: ~126,000
 ** obj2: ~126,000
- Firefox 29:
 ** map: ~176,000
 ** obj: ~120,000
 ** obj2: ~120,000

Florent
Flags: needinfo?(fayolle-florent)
Thanks, Florent!
As Terrence said, let's this patch rides the trains.
I ran the test from Comment 0 on the latest Beta, Aurora and Nightly and a performance improvement is visible for Map objects:
- Firefox 32 Beta 8 32-bit (Build ID: 20140818191513): 
   * Windows 7 64-bit: ~210,506 ops/sec
   * Ubuntu 14.04 LTS 32-bit: ~228,872 ops/sec
   * Mac OSX 10.9.3: ~192,078 ops/sec
- Aurora 33.0a2 32-bit (2014-08-20): 
   * Windows 7 64-bit: ~206,413 ops/sec
   * Ubuntu 14.04 LTS 32-bit: ~217,237 ops/sec
   * Mac OSX 10.9.3: ~190,029 ops/sec
- Nightly 34.0a1 32-bit (2014-08-20): 
   * Windows 7 64-bit: ~188,523 ops/sec
   * Ubuntu 14.04 LTS 32-bit: ~199,078 ops/sec
   * Mac OSX 10.9.3: ~176,510 ops/sec 

I'm inclined to say that this is fixed. Terrence, what do you think?

P.S: my OS X test machine (a mac mini) is quite slower and older, hardware-wise.
Flags: needinfo?(terrence)
It's nice to see that even with GGC hurting this micro-benchmark, we're still well ahead of where we were a few months ago from other improvements in the engine. I expect that the minor slowdown on nightly is due to the extra debugging code we have enabled there, so probably isn't a regression.

I agree that this is indeed fixed. Thanks for re-running the benchmarks, Andrei!
Flags: needinfo?(terrence)
This issue is now verified fixed. Thank you for following up on this, Terrence!
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.