js-tokens: Use explicit source preload

[camillobruni]

Using the function source is technically not defined to always return the source string.
Additionally this forces chrome to use a special external string type since it's rather uncommon to access the function source.

Until we can fix the resource loading to handle duplicate entries for files and preload data we will duplicate the js-tokens.js file to get a separate name.

Addresses issue #271.

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	5a6d7f4
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/697b5fcd9187d400072de78b
😎 Deploy Preview	https://deploy-preview-270--webkit-jetstream-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[camillobruni]

I actually mis-mesured since I was doing this on the command line instead of the browser where we actually the full external string implementation:

Before (10 runs):

browser          Google Chrome Beta     Safari Technology Preview  Firefox
version          145.0.7632.26          26.0.0.234.20624.1.6.19.3  147.0.1
cpu              Apple M1 Max 10 cores  Apple M1 Max 10 cores      Apple M1 Max 10 cores
js-tokens/Score  186.0 ± 3.2%           328 ± 4.3%                 281.9 ± 1.2%
Score            186.0 ± 3.2%           328 ± 4.3%                 281.9 ± 1.2%

After (10 runs):

browser          Google Chrome Beta     Safari Technology Preview  Firefox
version          145.0.7632.26          26.0.0.234.20624.1.6.19.3  147.0.1
js-tokens/Score  347.2 ± 1.3%           324 ± 5.1%                 213.3 ± 0.60%
Score            347.2 ± 1.3%           324 ± 5.1%                 213.3 ± 0.60%

[kmiller68]

Seems like we should just eval the source code here to inject jsTokensWrapperFunction into the global namespace. That way we can delete the code above and have a single source of truth for the wrapper function and we don't run the risk of the two diverging in the future.

[camillobruni]

d8:           143.10 ±  5.80  ->  138.30 ±  7.10  ( -3.4%)
jsc:          159.90 ±  8.60  ->  145.00 ± 10.00  ( -9.3%)
spidermonkey: 102.60 ±  2.40  ->  139.70 ±  9.60  (+36.2%)

Maybe this needs double checking for spidermonkey?

[iainireland]

Double-checking locally, the speedup seems accurate for SM. The old approach used evaluate under the covers, for which we always inflate the source to two byte characters. It's also longer than our internal limits for deflating to one-byte characters in Function.toString. The new implementation enables our one-byte character fast-paths.

EDIT: But that is specific to the shell. The browser implementation might actually be flipped, with the old code getting 1-byte strings and the new code getting 2-byte strings. Are the browser numbers above still accurate?