Open
Bug 1118938
Opened 10 years ago
Updated 2 years ago
Fix browsermark-js-knockout performance
Categories
(Core :: JavaScript Engine: JIT, defect, P5)
Tracking
()
NEW
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!
Reporter | ||
Updated•10 years ago
|
Attachment #8546043 -
Attachment is obsolete: true
Comment 1•10 years ago
|
||
(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
Reporter | ||
Comment 2•10 years ago
|
||
(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
Comment 3•10 years ago
|
||
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.
Reporter | ||
Comment 4•10 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•