Closed Bug 1015618 Opened 5 years ago Closed 5 years ago
Consequent performance regression with Map objects in Firefox 31
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
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
(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.
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)
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.
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.
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
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.
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!
This issue is now verified fixed. Thank you for following up on this, Terrence!
You need to log in before you can comment on or make changes to this bug.