New Workload: JSDOM + d3 #124
Conversation
✅ Deploy Preview for webkit-jetstream-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Typo: d3. |
There was a problem hiding this comment.
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.
| }, | ||
| tags: ["d3", "startup", "jsdom"], | ||
| iterations: 10, | ||
| worstCaseCount: 4, |
There was a problem hiding this comment.
Seems like a high worstCaseCount for the number of iterations.
| airportsBlob: "./jsdom-d3-startup/data/airports.csv", | ||
| }, | ||
| tags: ["d3", "startup", "jsdom"], | ||
| iterations: 10, |
There was a problem hiding this comment.
These iterations are pretty fast, it seems like we could do more like 15-20.
|
Looks like the officially bundled d3 has some non-ascii chars in it, so there seems to be some precedent for this.
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? |
|
IIRC, all browsers natively support Latin-1 and UTF-16 strings so 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. |
|
|
Also filed d3/d3#4043 since I can easily reproduce and fix this locally now. |
Startup focused d3 + jsdom workload.