[camillobruni]

Startup focused d3 + jsdom workload.

• Evals unique sources per iteration (custom babel plugin which injects comments into each function)
• Measures d3 demo including parsing csv
• Uses bundled jsdom as mock library

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	9aedd70
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/68f909bd31334a00081c16ab
😎 Deploy Preview	https://deploy-preview-124--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.

[kmiller68]

Startup focused d2 + jsdom workload

Typo: d3.

[kmiller68]

Would be Ince to have a README.md with steps to rebuild the minified sources and whatnot.

The minified sources also don't seem to escape the non-ascii characters, which makes the whole file parse as non-ascii. I'm not sure how many sites actually do that but if that's uncommon (which AFAIK it is) we should probably do that escaping.

[camillobruni]

Looks like the officially bundled d3 has some non-ascii chars in it, so there seems to be some precedent for this.

• https://cdnjs.cloudflare.com/ajax/libs/d3/7.9.0/d3.min.js
• source.match(/[^\x00-\x7F]/g) === ['µ', '−'] (µ at least is still in 0xFF range I think)

Given that we don't have that really in other files, I'd be fine with it. But I'm not sure how robust thee non-ascii handling is across shells?

[kmiller68]

IIRC, all browsers natively support Latin-1 and UTF-16 strings so µ would be fine but − doesn't appear to be Latin-1 indeed. Pretty unfortunate that one character would cause all browsers to parse that file as UTF-16... maybe we should let them know.

On the other hand, I'm not sure how much work we want to do to optimize parsing of non-Latin-1 sources, since no matter what it's going to be slower and use more memory than Latin-1 minified sources. I'd be more open to it if the benchmark were less parsing focused. But this entire benchmark is just parsing, from my initial profiling anyway.

[camillobruni]

• Added README.md
• Used UnicodeEscapePlugin to ensure ascii encoding

[camillobruni]

Also filed d3/d3#4043 since I can easily reproduce and fix this locally now.

[kmiller68]

LGTM, we can change the iteration count in a follow up if you want.