Open
Bug 861070
Opened 12 years ago
Updated 2 years ago
Activating SPS profiling severely deoptimizes emscripten code
Categories
(Core :: Gecko Profiler, defect, P3)
Tracking
()
NEW
People
(Reporter: kael, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
When attached test case is run normally for me in Firefox 22, elapsed time is roughly around 1800ms for the last test case (so the last line shows a timing of around 1800ms).
Simply turning on SPS sampling causes the elapsed time to become nearly 3000ms.
Alongside this, the SPS samples show individual functions calling each other - the methodinvoker calls toWireType and the actual target function, and they each are getting samples and CPU time.
With SPS turned off, JIT Inspector's view of the generated Ion code for the methodinvoker shows that toWireType and the target function have been inlined into the methodinvoker.
Everything I can see here suggests that SPS is disabling inlining, perhaps to ensure that it has 'correct' stacks that would otherwise be mangled by inlining. If so, that's fine, but it calls into the question of making SPS default on if it's going to degrade JS performance... and degrading JS performance this much calls into question its usefulness as a JS profiler.
Comment 1•12 years ago
|
||
I should point out that this is non-asm.js Emscripten code.
Reporter | ||
Comment 2•12 years ago
|
||
Good catch, yeah. It isn't asm.js, sorry.
Comment 3•12 years ago
|
||
I should also point out that all asm.js calls will be summarized with a single entry, atm. (This entry is also missing from the builtin FF profiler since it is a "native" entry and the builtin FF profiler only shows JS entries.)
Comment 4•12 years ago
|
||
The SPS profiler doesn't (or, at least, isn't intended to) disable inlining: instead, it adds special MIR nodes that designate the boundaries of the inlined function, pushing frame data to the SPS stack. Profiling does cause the generated code to use one fewer register, which would impact performance on 32-bit builds, but I wouldn't expect a regression of this magnitude.
Reporter | ||
Comment 5•12 years ago
|
||
I had hoped that it was adding book-keeping data like those MIR nodes and not actually suppressing inlining, so that's really good to hear. Are there steps I could take to try and identify why the performance regression is so severe, then - like dumping the generated jitcode somehow?
Comment 6•8 years ago
|
||
This testcase is 1700ms without the profiler and 2200ms with the profiler (+ JS profiling) on my machine. So still a slowdown of about 25%. This is on a 64 bit Mac.
Severity: major → S3
Priority: -- → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•