1822734 - JS demo (https://www.fxhash.xyz/generative/slug/serendipity-vs-consequence) appears to spend large-ish time in js:frontend

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Mayank Bansal]

Go to https://www.fxhash.xyz/generative/slug/serendipity-vs-consequence
Click on "Run"
Optionally, click on "Variations" a few times

Profile (Strategy=0): https://share.firefox.dev/3JJLXvJ
Profile (Strategy=1): https://share.firefox.dev/3Lw3msW
Profile (Strategy =2): https://share.firefox.dev/3FnE0tx
Profile (Strategy=3): https://share.firefox.dev/3ldYiPo
Profile (Strategy = 255): https://share.firefox.dev/3YLmtCk

Profiler suggests large-ish time spent in the frontend.

Comment 1

[Ted Campbell [:tcampbell]]

Interesting case. The large amount of parse time you see here is from the page's use of eval and shows up in the profile as time spent under js::frontend::CompileEvalScript.

To address this, we'd an improved sort of eval script caching which is more possible these days after the Stencil work.

The other unusual thing I see here is that a surprising portion of the parse (15%) is spend in js::frontend::ParserBase::setSourceMapInfo. We have seen similar things in the past where complex data URLs can become slow for this sort of dynamic code. I previously added the string deduplication step to avoid explosion of memory usage on other pages that made heavy use of eval on dynamic code.

Comment 2

[Ted Campbell [:tcampbell]]

A small defect that might make sense here to fix is that we duplicate a the string before checking for duplicates. This avoids rapid memory growth, but is a silly waste of CPU time. Some gentle refactoring of the SharedImmutableString code might allow us to avoid this.

https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/js/src/vm/JSScript.cpp#1991,1995