New Workload: Babylon class-heavy workload #143
Conversation
✅ Deploy Preview for webkit-jetstream-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
camillobruni
changed the title
|
Can we add the |
- use unicode converter plugin - Use startup-helpers
|
It seems like the scene workloads seem to block or stall for several seconds in Safari but not JSC cli or other browsers. Have you seen that at all? I can investigate more tomorrow, if not. 
vs JSC cli, which is much more reasonable: 
|
…-14_class-startup
- Use Object.keys to access exported names intead of the more uncomment class names - Monkey patch setTimeout that was accidentally used in the scene - Move cheap validation into the runIteration to leak fewer objects across iterations
|
I've now patched setTimeout for both workloads. I think this was accidentally used in the scene workload. Could you double check again whether this is still blocking / adding dead time? |
There was a problem hiding this comment.
The test itself looks good from the samples, although, it's using a ton of memory in JSC/V8/SM cli (1+ GB) on my Mac. It seems to consistently grow over time. Maybe there's an internal memory leak within the benchmark? I just ran them together with the edit: I thought it was using a bunch of memory but I forgot to artificially limit the ram size of JSC or send low memory warnings. I think it's actually fine.babylonjs tag.
With these big tests I like to make sure the scores are consistent between all the browsers and the CLIs. With SP3 we found there were some polyfills that ended up running for us but not for other browsers, which wouldn't make sense for JS3. That didn't seem to be the case here, so it seems all good on that front.
|
Seems like the CI is broken. We should probably fix that before merging. |
|
LGTM. I need to get some of our tooling updated so that I can do a better job of profiling only the parts of the test in measured time, but from just eyeballing it, it all seems reasonable. I see lots of time spent parsing, anyway, which is what we were going for. |
3 participants
Applying the same cache-busting pattern, I've created a Babylon.js-based startup workload.
There is an ES6 and ES5 version of the same workload and they both heavily stress parse+top-level setup code with many classes.