Open Bug 1118938 Opened 7 years ago Updated 5 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
(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
You need to log in before you can comment on or make changes to this bug.