Open Bug 1118938 Opened 10 years ago Updated 2 years ago

Fix browsermark-js-knockout performance

Categories

(Core :: JavaScript Engine: JIT, defect, P5)

x86_64
Linux
defect

Tracking

()

People

(Reporter: h4writer, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

We currently have 2329 on "Scalable Solutions Knockout 2.1", which is quite bad compared to v8 having 8921. Being a bit slower on a benchmark is possible. Both engines are quite close on most benchmarks. Here we are 3 times slower. So we must be doing something stupid here. Investigate and fix!
Depends on: 1118953
Attachment #8546043 - Attachment is obsolete: true
(In reply to Hannes Verschore [:h4writer] from bug 762449 comment #31) > FYI I was looking at the browsermark 2.1 knockout benchmark score. The > difference between v8 and spidermonkey is the time we spend in > "compareSmallArrayToBigArray" first loop. Which is currently mostly MinorGC, > "freeHugeSlots", which does only js_free. > > I created a js shell benchmark out of it in bug 1118938. The numbers should > somewhat relate to the full browsermark, but the scores reported here are > from the shell benchmark. > > On trunk we have scores 2900ms with the first loop taking 1000ms. (On linux > the loop takes 500ms, due to faster js_free). free is slower on mac because it needs to determine whether something was allocated by jemalloc or by the system allocator first. If ozone_size in mozjemalloc and zone_size in jemalloc3 appear to be a significant portion of runtime in a profile, we could make a case to have the js engine call jemalloc directly instead of going through the zone allocator. > I was told by ehoogeveen to test jemalloc3, since it could potentially > improve scores. Bad luck here: > total score become: 3398ms, while the loop now takes 1422ms! Can you try again with jemalloc3 with the following environment variable set, and report corresponding numbers? JE_MALLOC_CONF=lg_dirty_mult:3
(In reply to Mike Hommey [:glandium] from comment #3) > > I was told by ehoogeveen to test jemalloc3, since it could potentially > > improve scores. Bad luck here: > > total score become: 3398ms, while the loop now takes 1422ms! > > Can you try again with jemalloc3 with the following environment variable > set, and report corresponding numbers? > JE_MALLOC_CONF=lg_dirty_mult:3 total: 3389ms, loop:1338ms
Depends on: 1122523
Depends on: 1122640
How do you run that testcase to get those numbers out of it? All I'm getting is numbers from 0 to 1000 printed out in the page, followed by FINISHED.
In the shell will the last number be the time it took js /tmp/test.js In the browser, you will need to open the console and you will see the elapsed time in there.
Depends on: 1138881
Depends on: 1146440
Depends on: 1146597
Blocks: jsperf
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.