1647276 - Performance issue when using JavaScript within the Console

Status: NEW

(DevTools :: Console, defect)

Description

[Nicolas B. Pierron [:nbp]]

What were you doing?

I tested the performance issue reported in https://news.ycombinator.com/item?id=23598740

When copying the content of the JSFiddle script in the devtools console, bad performance numbers are reported.

Note, that the problem does not appear when running the same script in a dedicated page which only has a script tag surrounding the content.

What happened?

The performance was slow, and unexpected.

What should have happened?

We have multiple options:

• Either, we report as part of the console/debugger UI that the performance should not be expected in the devtools console when noticing long running application, as the console is optimized for debugging.

• Or, we fix the JavaScript engine to make sure we have the same performance, at the cost of lacking information to report in the debugger.

Comment 1

[Nicolas B. Pierron [:nbp]]

This might be a duplicate of Bug 793345

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

Nicolas, could you record a profile with Firefox profiler and attach it here so we can check what's happening?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2)

Nicolas, could you record a profile with Firefox profiler and attach it here so we can check what's happening?

https://profiler.firefox.com/public/b73944d947c6b0470821c86f298ab7330243b660/calltree/?globalTrackOrder=0-1&localTrackOrderByPid=12142-1-2-0~12414-0~&thread=2&v=4

The profile only highlight that we are running the benchmarks. Which does not add much useful information to what is already reported here. I stopped the profile after seeing the "stop it / wait" popup. The benchmark is also reported as running under Ion, but as Bug 793345 suggest, the way the evaluation is setup causes the performance issue.

I think reporting that the console is not meant to test benchmark as soon as performance.now / Date.now are called within the console, would be a good approach to avoid developer reporting alarming performance results.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:nchevobbe, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Nicolas B. Pierron [:nbp]]

Looking at comments since Bug 793345 comment 22, the problem seems to be that the devtools might be relying on executeInGlobalWithBindings, which is currently deliberately not optimized in the JIT.

Would it be possible to use a different entry point?

Comment 6

[Alexandre Poirot [:ochameau]]

DevTools do rely on executeInGlobalWithBindings on purpose over there:
https://searchfox.org/mozilla-central/rev/560b7b1b174ed36912b969eee0c1920f3c59bc56/devtools/server/actors/webconsole/eval-with-debugger.js#242-246
But could use some alternative implementation of it if you have suggestions.

The requirement is to eval some JS string, against a given global, with some additional variables (the "bindings").
Typically, in the console, we expose $0, $$, and many other symbols, implemented over there:
https://searchfox.org/mozilla-central/rev/560b7b1b174ed36912b969eee0c1920f3c59bc56/devtools/server/actors/webconsole/utils.js#261

That's the main reason why we don't use the simplier executeInGlobal, as it doesn't allow to expose these symbols without leaking them to the webpage.