932075 - (find-unopt-JS) Find unoptimized JS Execution

Status: RESOLVED WONTFIX

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Axel Kratel]

as a web/app dev, it's valuable for me to know where in a recording my JS is being executed in an un-optimized way so that I can optimize my code to avoid such executions. 

Acceptance criteria:
* when looking at "time spent in JS" anywhere in the UI, should be able to visualize where the JS is spending time:
- GC
- compiling
- interpreter/parsing
- running in baseline
- running in ion-monkey
* The tool should highlight anywhere JS code is run un-optimized, i.e. running in baseline instead of ion-monkey.

Note: 
Ideally we want to be running in ionmonkey which is our optimized engine. We don't need to surface everything to web developers, but at the very least, we need to be able to tell them when their JS is executing sub-optimally.

Note: GC may need to be split into a separate user story.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Note: it doesn't matter if a given JS function / path is in baseline rather than ion if it isn't a performance bottleneck. Who cares if this function wasn't jit'd well if it was only called once?

Keeping that in mind, we can filter out HUGE swathes of data (which is noise to users) by only showing this info for hot code paths.

Comment 2

[David Bruant]

(In reply to Axel Kratel from comment #0)
> Note: 
> Ideally we want to be running in ionmonkey which is our optimized engine. We
> don't need to surface everything to web developers, but at the very least,
> we need to be able to tell them when their JS is executing sub-optimally.
If we can't say why and can't provide actionable hints to the developer, I feel this will be of very limited use.
Related: https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/tzAqxbDKXAI

Comment 3

[Jim Blandy :jimb]

Nick's point is a good one. One way to show de-optimization in a way that emphasizes when it made a difference and when it didn't would be to use a plot where area was proportional to time (as it is in [1], for example) and then use color to indicate how much optimization we were able to apply to it.

That way, code what was not optimized, but did not use much time, will appear as small splotches of the unpleasant color, while significant amounts of time spent in unoptimized code will appear as large blotches of unpleasant color.

[1] http://tracelogger.paas.allizom.org/index.php?subject=octane-splay-32410b741451

Comment 4

[Greg Tatum [:gregtatum]]

This user story is probably no longer relevant for current work. There have been many subsequent discussions about visualizing information in this way, but no planned and actionable work.