Open Bug 861070 Opened 12 years ago Updated 2 years ago

Activating SPS profiling severely deoptimizes emscripten code

Categories

(Core :: Gecko Profiler, defect, P3)

22 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: kael, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached file Test case (deleted) —
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.
I should point out that this is non-asm.js Emscripten code.
Good catch, yeah. It isn't asm.js, sorry.
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.)
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.
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?
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.
Blocks: 761253
QA Whiteboard: qa-not-actionable
Severity: major → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: