Explicit compile hints

[marjakh]

WebKittens

No response

Title of the spec

Explicit compile hints

URL to the spec

https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based/

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

https://docs.google.com/document/d/19xTAM4A75tz0xUq_velMzGA4JHEgXpyflUxXTcuNiyE

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/780

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Knowing which JavaScript functions to parse & compile upfront can speed up web page loading.

Some example numbers from our experiments:

• Data set of 4 big web pages, local cold runs: Parse + compile time decreases 4 - 13 %, foreground parse + compile time decreases 59 - 86%.
• Internal web devs report 5% improvement in their page load time metrics w/ PIFEing all functions in core file.

Currently, V8 uses the PIFE heuristic to direct which functions to compile. This heuristic has existed for a long time and is well known to web developers. V8 and SpiderMonkey follow the PIFE heuristic, but JavaScriptCore doesn't.

Using PIFEs for transmitting information about which functions should be eager-compiled has downsides, though. Especially:

• using it forces using function expressions instead of function declarations; this might regress in all browsers, and for browsers which don't follow the PIFE hint there's no upside
• it cannot be applied to ES6 class methods

Thus, we want to experiment with other ways to transmit compile hints.

We don't want to cause extra work for browsers who don't want to support compile hints; we'll only explore options where ignoring the hints happens naturally.

We're currently starting early experiments with potential users, and will create the actual spec based on feedback.

[hober]

Added concerns: venue because, at first blush, it seems like this should be proposed in the context of TC39.

[marjakh]

We don't expect TC39 to be the right venue, since we don't plan to suggest semantic changes to the JavaScript language. Adding compile hints as magic comments or directives won't produce any observable differences (aside performance).

E.g., magic comments for source mapping URLs ( https://sourcemaps.info/spec.html )

//# sourceMappingURL=<url>

are also not specced by TC39.

[annevk]

Nevertheless, no venue at all is problematic (for Source Maps too) in terms of IPR and governance.

[msaboff]

I agree with @hober. Why do we think that TC39 is NOT the right venue?

If this is a performance benefit for browsers, why don't we think it would also benefit other JavaScript code bases like Node?

At a minimum, a proposal should be given to TC39 to see if there is broader interest.

[syg]

Why do we think that TC39 is NOT the right venue?

Primarily because, as this has no observable semantics for JS, I'm not sure what there is to seek consensus for. We can certainly present it as a call for collaboration and to gauge interest, however.

I hear you on the IPR and governance concerns, perhaps WICG?

[RByers]

Note there's an Intent to Ship for this in Chromium. Definitely we prefer to see this in a venue with good IPR etc, but we need a signal of interest from another party in order to do that. Is WebKit interested?

[kmiller68]

I don't have enough opinions yet to say we'd want to / would consider shipping this too. I mainly worry that anything easily generated by hand and not a PGO tool is too easy to misuse. I also worry that either way the set of things picked will be tuned for the dev's favorite browser and be suboptimal for other browsers.

That said, I have a few drive-by thoughts from looking at the proposed spec:

• It seems like some kind of place for a version would be good practice.
• IMO, https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based/#extract-compile-hint-annotation should bail if any non-comment (I guess including #!) are detected before the hint. Putting a hint partway down the file and expecting it to work would be weird.
• Why allow both @ and # to prefix the comment https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based/#matching-compile-hint-annotation? Seems like just picking one would be better. (The explainer uses # so I guess that seems like logical/existing choice)

[annevk]

Definitely we prefer to see this in a venue with good IPR etc, but we need a signal of interest from another party in order to do that.

It seems some improvement over a Google Doc should be possible even without signals from other parties? E.g., a TC39 proposal (was it ever presented to TC39?) or indeed WICG.

[syg]

The current plan is WICG. It's a poor fit as a TC39 proposal since it has no observable semantics. It will be presented at TC39 this week though as an info session.

[marjakh]

Thanks for your feedback, Keith!

We'll think about how adding a version number might work.

I don't feel strongly about whether putting the hint partway to the file should make the rest of the file eager. If folks feel it's better to make that be a no-op, I'm open to that idea. With just concatenating with compile hints, if the first file happens to have a compile hint, the whole big file will be made eager, which is also not the wanted result. As a follow-up (not in the first version), I'm also thinking about adding "eager compilation scopes" which would make it easier to retain the information when files are being concatenated.

Oops, the # vs @ was a copy-paste error from source maps; the intention is to only allow #. I'll update the spec draft after TC39. Thanks for pointing that out.