Summary: | 4x slow execution slowdown when comparing the same codebase targeting ES2015 vs. ES5 | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mihai Parparita <mihaip> | ||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED DUPLICATE | ||||||
Severity: | Normal | CC: | beidson, evan.exe, fpizlo, keith_miller, mjs, saam, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Mac | ||||||
OS: | macOS 10.15 | ||||||
Attachments: |
|
Description
Mihai Parparita
2020-06-09 00:02:28 PDT
I have observed the same time difference in the current WebKit nightly build (r262775) As a further experiment, I generated a variant of the ES2015 output that did not wrap the output in an IIFE, and that had comparable performance to the ES5 output that did: http://persistent.info/webkit/test-cases/es2015-slowness/?es2015-no-iife - takes around 91ms However, that pollutes the global namespace (and exposes symbols that we would prefer not to be accessible). If we take the script and load it with <script type="module">, then we're back to where we started from: http://persistent.info/webkit/test-cases/es2015-slowness/?es2015-no-iife-module - takes around 330ms So taking off the IIFE and using module scripts is not a feasible workaround for us. These are the sources for the variants used: http://persistent.info/webkit/test-cases/es2015-slowness/es5.js http://persistent.info/webkit/test-cases/es2015-slowness/es2015.js http://persistent.info/webkit/test-cases/es2015-slowness/es2015-var.js http://persistent.info/webkit/test-cases/es2015-slowness/es2015-no-iife.js Saam: It looks like you've looked into IIFE and TDZ-related performance issues in the past, any chance you could see if there's anything that could be done from the JSC side? I think you are seeing the same issue that came up in https://bugs.webkit.org/show_bug.cgi?id=199866. It seems like this is a more widespread problem that we should solve. I'll try to find time to work on it soon! Although, I no longer remember what the solution I had in mind back then was... 🤦♂️ Closing in favor of bug 199866 -- it's the same underlying issue and that one has more traction. *** This bug has been marked as a duplicate of bug 199866 *** |