Open
Bug 1352486
(emberperf)
Opened 8 years ago
Updated 2 years ago
[meta] Improve performance on EmberPerf benchmark
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
People
(Reporter: evilpie, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: meta, perf, Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS])
http://emberperf.eviltrout.com/
I just ran "Render Complex List" on Nightly and we are only about half as fast as Chrome.
Comment 1•8 years ago
|
||
Dupe of bug 1133864? Or at least that bug should depend on this one.
Comment 2•8 years ago
|
||
I'll take a look next week. I also want to figure out where that high error % comes from.
Flags: needinfo?(jdemooij)
Comment 3•8 years ago
|
||
Jeff Atwood reports that Chrome Canary and Edge both recently doubled their "Render Complex List" performance:
https://twitter.com/codinghorror/status/841775015917887488
https://twitter.com/codinghorror/status/847693460572225536
Keywords: perf
Updated•8 years ago
|
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS]
Comment 4•8 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #2)
> I also want to figure out where that high error % comes from.
Part of this is EAGER_ALLOC_TRIGGER GCs, if I just disable that GC trigger my error % drops from > 100% to 75-80%. That's still nothing to be proud of, but it suggests GC definitely plays a role here. The next step is understanding what kind of GC things we allocate here.
Comment 5•8 years ago
|
||
OK, we're allocating (among other things) a lot of FAT_INLINE_STRING, STRING, and EXTERNAL_STRING arenas. There might be some easy wins here like bug 1352323. It's unfortunate we don't nursery allocate strings yet because I bet many of these are short-lived.
Depends on: 1352323
Comment 6•8 years ago
|
||
Ember (still) has some terrible logging. We're allocating many strings here:
_glimmerUtil.LOGGER.debug('[VM] OP ' + opcode.type);
The debug-function is quite complicated so it's not trivial for the JIT to optimize this concatenation away.
We really want to use nursery allocation for these strings so we don't trigger full GCs.
Depends on: 903519
Comment 7•8 years ago
|
||
nominating for QF triage
status-firefox52:
--- → wontfix
status-firefox53:
--- → affected
status-firefox54:
--- → affected
status-firefox55:
--- → affected
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS] → [platform-rel-Frameworks][platform-rel-EmberJS][qf]
Reporter | ||
Comment 9•8 years ago
|
||
I think we should be mentioning the logging issue to the Ember team, seems like something they could be interested in fixing on their side.
(In reply to Tom Schuster [:evilpie] from comment #9)
> I think we should be mentioning the logging issue to the Ember team, seems
> like something they could be interested in fixing on their side.
:jandem and others have access to our mailing list with the Ember core team. I'd encourage them reaching out if we deem that Tom Dale and others would find this interesting...
Updated•8 years ago
|
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS][qf] → [platform-rel-Frameworks][platform-rel-EmberJS][qf:p1]
Comment 11•8 years ago
|
||
The code is transpiled to JS (Babel) and Object.setPrototypeOf is used on functions to represent class inheritance. This confuses TI and we don't inline these functions in Ion, and then we end up with megamorphic ICs. This should be fixable, I just need to figure out the best way to do it.
Comment 12•8 years ago
|
||
Robert Jackson says Ember's new debug stripping should remove the logging function calls and avoid the string allocations. The Ember team is considering back porting to Ember LTS (2.12).
https://github.com/glimmerjs/glimmer-build/pull/42
Updated•8 years ago
|
Alias: emberperf
Keywords: meta
Summary: Improve performance on Ember → Improve performance on EmberPerf benchmark
Comment 13•8 years ago
|
||
Here is a link to a profile from a user that was viewing Twitch (which uses the Ember framework, apparently), in the background:
https://perfht.ml/2qAJFHe
Quite a bit of main thread jank on Content Process 5. Not sure if this is useful, but thought I'd attach.
Updated•7 years ago
|
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS][qf:p1] → [platform-rel-Frameworks][platform-rel-EmberJS][qf:p2]
Updated•7 years ago
|
Flags: needinfo?(jdemooij)
Comment 14•7 years ago
|
||
How's the situation changed with Fx 55 and Bug 1352323 fixed?
Comment 15•7 years ago
|
||
I see no improvement in Firefox 55 or 56 on my Windows 10 laptop. Results for the "Render Complex List" test with Ember version 2.13.0:
* Firefox 54 = 12.56 ops/sec
* Beta 55 = 12.89 ops/sec
* Nightly 56 = 12.04 ops/sec
* Edge 15 = 16.20 ops/sec
* Chrome 60 = 39.24 ops/sec
status-firefox56:
--- → affected
Comment 16•7 years ago
|
||
You can follow on https://arewefastyet.com/#machine=35&view=breakdown&suite=emberperf
Updated•7 years ago
|
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS][qf:p2] → [platform-rel-Frameworks][platform-rel-EmberJS][qf:meta]
Updated•7 years ago
|
Priority: -- → P3
Updated•3 years ago
|
Performance Impact: --- → ?
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS][qf:meta] → [platform-rel-Frameworks][platform-rel-EmberJS]
Updated•3 years ago
|
Summary: Improve performance on EmberPerf benchmark → [meta] Improve performance on EmberPerf benchmark
Updated•3 years ago
|
Performance Impact: ? → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•