1037764 - Significant performance regression in JSIL test case (array operations?) caused by generational GC

Status: RESOLVED WONTFIX

(Core :: JavaScript: GC, defect)

Description

[Katelyn Gadd (:kael)]

Attachment: FuseePackedVertices.cs.out

This test case ('FuseePackedVertices') runs some code from an end-user's application with a few different optimization modes applied. It used to be that the loop body using normal JS arrays was fastest (to be expected, honestly) and the two optimization modes (using dense typed arrays as a backing store) were somewhat slower, but acceptable in performance.

Chrome used to be utter garbage at this test case; it has since gone from utter garbage to acceptable to incredibly fast (the 38 timings are *so good* that I wonder if they found a way to optimize part of the test out...)

In comparison, FF's performance timings for the two packed array test cases have remained relatively constant while the normal JS array test case has gotten *considerably* slower.


FF 29.0.1 (release)

Array: 00255.00ms
Packed Array: 00794.00ms
Packed Array Alternate: 00528.00ms


FF 30.0 (release)

Array: 00306.00ms
Packed Array: 00879.00ms
Packed Array Alternate: 00549.00ms


FF 33.0a1 (2014-07-11) (nightly)

Array: 01159.00ms
Packed Array: 00791.00ms
Packed Array Alternate: 00554.00ms

Nightly SPS recording http://people.mozilla.org/~bgirard/cleopatra/#report=8eeb0162f25f15032fe0bab70b7571b828e0a9ae


Chrome 35.0.1916.153 m (release)

Array: 00397.00ms
Packed Array: 00295.00ms
Packed Array Alternate: 00605.00ms


Chrome 38.0.2087.0 (canary)

Array: 00092.00ms
Packed Array: 00127.00ms
Packed Array Alternate: 00249.00ms


Attaching test case JS source for now; going to package it up into a standalone JS test shortly. 

From the SPS recording it looks like the normal JS array test case spends tons of time in write barriers and GC; maybe this was 'regressed' by generational GC, and the garbage created by the test triggers some gen0 GCs where before the cost was offloaded to a GC that occurred outside the test run?

Comment 1

[Katelyn Gadd (:kael)]

Attachment: Relevant bit of SPS recording

Comment 2

[Katelyn Gadd (:kael)]

mozregression range

Last good nightly: 2014-03-28
First bad nightly: 2014-03-29

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa163ff81a3&tochange=4f3443da36a1

Comment 3

[Till Schneidereit [:till]]

CC-ing GC people and moving to GC component.

Comment 4

[Katelyn Gadd (:kael)]

http://jsil.org/try/#f691d9f62df671f99803

Click 'Compile & Run' to run the testcase. It loads in the iframe.

Comment 5

[Jon Coppeard (:jonco)]

In reply to K. Gadd (:kael) from comment #1)

From the profiler output it seems like we're spending a lot of time compacting the whole cell store buffer.

Comment 6

[Katelyn Gadd (:kael)]

Attachment: FuseePackedVertices.cs.out (v2)

I've updated my backend & codegen since I filed this bug, so the timings from the test case are a bit different:

Array: 01181.00ms
Packed Array: 00197.00ms
Packed Array Alternate: 00546.00ms

Arrays are still slow due to the GC, I just wanted to make sure people wouldn't be confused by getting significantly different timings.

Comment 7

[Katelyn Gadd (:kael)]

Interestingly, those timings are from a nightly jsshell - very fast.

Running it in the nightly browser, all 3 test cases are incredibly slow. I can't figure out why there's a difference.

Comment 8

[Till Schneidereit [:till]]

That might be related to incremental GC, perhaps?

Also CC-ing Hannes, who's been looking into performance differences between the shell and the browser.

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Jon Coppeard (:jonco) from comment #5)
> From the profiler output it seems like we're spending a lot of time
> compacting the whole cell store buffer.

Reminds me of bug 1022090, interestingly enough also filed by K. Gadd..

Comment 10

[Katelyn Gadd (:kael)]

The issue appears to be more specific than whether or not it's run in a browser. If I run it in the browser using a simple HTML file it's very fast. if the Try website loads it it's very slow. I'm not sure what the difference is. I'm going to file a bug about this...

Comment 11

[Katelyn Gadd (:kael)]

Attachment: HTML test runner

I'm attaching a ZIP that contains a HTML version of my test runner so you can get timings more easily.

There was a bug causing try.jsil.org to run the array test case 3 times since it was the first test case. It's fixed now - sorry if anyone tried looking deeper into the timing results from Try and got confused.

To benchmark it, load 'test_runner.html#Tests/PerformanceTestCases/FuseePackedVertices.cs.out'.

I also increased the number of test iterations so you can get more useful data out of SPS.

Comment 12

[Mayank Bansal]

Code like this should target WASM these days.