Surprising performance difference between SM and v8

NEW
Unassigned

Status

()

Core
JavaScript Engine
5 years ago
3 months ago

People

(Reporter: evilpie, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Look at the difference in performance for test case "mraleph #1" and "mraleph #2" in v8 #2 is much faster, but we are slower.

http://jsperf.com/mostcommonword/11
Tweeted to me https://twitter.com/mraleph/status/363276568413483008.
Created attachment 785382 [details]
shell testcase of only the mraleph1 and 2 versions

Efaust, not that I expect you to work on this, but it looks to me like it might be related to things you recently dealt with, and you might have an idea of what causes it.

Note also that the shell testcase, while it exhibits roughly the same speed ratio between the two versions, runs roughly 3x as fast as the jsperf version. Of course, that might just be caused by jsperf overhead, but it might also be a difference between browser and shell versions.
Flags: needinfo?(efaustbmo)
I bet we do not inline node.prototype.step I think there is already open on the fact that TI does not give any singleton information and functions which are not attached to the global, which might prevent the inlining rules of IonBuilder to do anything.

Comment 3

5 years ago
Looking at how somebody optimized my code (a member of SM team?) and playing with things I figured out that the biggest hit seems to come from typeof v === 'undefined' pattern.

V8 actually recognizes it already on the AST level IIRC (as this pattern was very common in built-ins code way before V8 got Crankshaft).

Replacing typeof v === 'undefined' with v === void 0 gives almost a 2x improvement on SM, but no improvement on V8. 

I moved the code (leaving behind the slow test cases) to

http://jsperf.com/mostcommonword-only-fast/3
(In reply to Vyacheslav Egorov from comment #3)
> Looking at how somebody optimized my code (a member of SM team?) and playing
> with things I figured out that the biggest hit seems to come from typeof v
> === 'undefined' pattern.

Oh, right, that's bug 470143. Thank you for analyzing this!
Depends on: 470143
(Reporter)

Comment 5

5 years ago
I wonder if this was fixed by Bug 914132.
Today's Nightly is quite a lot faster than a build from two days ago. For mraleph1, I get 23 Ops/s instead of < 15 (vs 22 in Chrome), and for mraleph2, I get 28 Ops/s instead of ~14 (vs 61 in Chrome). The other tests are all close-ish, but most are still a bit faster in Chrome.

That still leaves us with half the speed on mraleph2, so the typeof improvements weren't the whole story.
(Assignee)

Updated

4 years ago
Assignee: general → nobody
We're faster than v8 on this now, at least on the shell test: 47ms/15ms vs 55/17. JSC is quite a bit faster on the first test, though: 38/18.

Probably not worth looking into right now, but keeping it open.
Flags: needinfo?(efaustbmo)
You need to log in before you can comment on or make changes to this bug.