Open
Bug 870627
Opened 12 years ago
Updated 1 year ago
Slow performance on GWT benchmarks
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
NEW
People
(Reporter: azakai, Unassigned)
References
(Depends on 2 open bugs, Blocks 1 open bug)
Details
Attachments
(2 files)
https://dl.dropboxusercontent.com/u/80664946/gwt.tar.bz2
has 4 GWT-compiled benchmarks (run "benchmark.html" in each directory, and see results in the web console). Firefox (nightly) does far worse than chrome (dev), by more than an order of magnitude in most of them,
firefox chrome
binary trees 11.96 0.57 seconds
linpack 56.03 1.06
meteor 1.82 0.26
nbody 63.78 6.72
And even on the best one there is a 7x slowdown.
Comment 1•12 years ago
|
||
That is indeed bad! I created a shell version for the worst of the four. (Haven't look into the reason yet)
Comment 2•12 years ago
|
||
linpack:
- interp: 27s
- baseline: 8s
- ion: 50s
That definitely looks like a fault in IM. Quick check shows that we are losing a lot of time in GetElementIC::update. Looks like most caches are disabled. So we are missing an IC for something...
Comment 3•12 years ago
|
||
To be exact we are missing a Native[Int32] getelem
Comment 4•12 years ago
|
||
After bug 870814, what is the perf here?
Comment 5•12 years ago
|
||
(In reply to Luke Wagner [:luke] from comment #4)
> After bug 870814, what is the perf here?
No need to remeasure. Still way too slow ;). (At best this patch improves the scores with 30%). I don't know how much is related to the fact we use a ic cache instead of specific slotloads. But I think that will bring another improvement. That's on my todo list ;)
Comment 6•11 years ago
|
||
(In reply to Hannes Verschore [:h4writer] from comment #5)
> I don't know how much is related to the fact we use a
> ic cache instead of specific slotloads.
Jan suggested to look to baseline caches to decide when to use slotloads. This didn't yield an improvement. Maybe
Depends on: 874882
Comment 7•11 years ago
|
||
(In reply to Hannes Verschore [:h4writer] from comment #6)
> Jan suggested to look to baseline caches to decide when to use slotloads.
> This didn't yield an improvement. Maybe
Scratch that comment. This does increase performance. That's the reason I added that depending bug ;).
Getting close to v8 performance now !!
Comment 8•11 years ago
|
||
nightly
binary trees 14.7
linpack 3.22
meteor 0.512
nbody 4.093
So Binary trees hasn't improved. linpack/meteor improved substantially. And nbody is now faster than chrome.
Comment 9•11 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 10•9 years ago
|
||
I just tested this:
binary trees
fx - 7.878s
ch - 0.936s
linpack
fx - 2.21s
ch - 40.65s [??]
meteor
fx - 0.674s
ch - 0.393s
nbody
fx - 2.562s
ch - 3.029s
Updated•2 years ago
|
Severity: normal → S3
Comment 11•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:sdetar, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(sdetar)
Updated•2 years ago
|
Flags: needinfo?(sdetar)
Comment 12•1 year ago
|
||
Measuring the benchmark in Comment 1 today on my M1 MBP I find SM is 30% behind v8,
Blocks: jsperf
You need to log in
before you can comment on or make changes to this bug.
Description
•