ES2020 optimizations #3687
ES2020 optimizations #3687
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
| for (const [responseName, fieldNodes] of fields.entries()) { | ||
| const fieldsEntries = Array.from(fields.entries()); | ||
| for (let i = 0; i < fieldsEntries.length; i++) { | ||
| const { 0: responseName, 1: fieldNodes } = fieldsEntries[i]; |
There was a problem hiding this comment.
| const { 0: responseName, 1: fieldNodes } = fieldsEntries[i]; | |
| const [responseName, fieldNodes] = fieldsEntries[i]; |
This version is less wierd
There was a problem hiding this comment.
That version invokes the iterator and is very slow though
Explanation: `Object.create(null)` returns value of `any` type. So bellow construct is not reported by TS even in "strict" mode: ```ts const foo = Object.create(null); ``` Fixing this issue in `extendSchema` requires adding more code since we can't put all extensions nodes into one collection without loosing typesafety.
Explanation: `Object.create(null)` returns value of `any` type. So bellow construct is not reported by TS even in "strict" mode: ```ts const foo = Object.create(null); ``` Fixing this issue in `extendSchema` requires adding more code since we can't put all extensions nodes into one collection without loosing typesafety.
Context: I wanted to try more automatic alternative to graphql#3687 that allows us to continue using ES6 features without perfomance lost.
|
@JoviDeCroock Thanks for PR and research. BTW, your branch is still faster in some tests but slower in others: |
|
@IvanGoncharov #3691 optimizes some problematic ones, you might want to add a plugin like https://babeljs.io/docs/en/babel-plugin-transform-destructuring or the one from react-hooks because they transform If you want I can also close this as your transform approach looks better to me, thank you! EDIT: if you want I can write that transformer as well |
Context: I wanted to try more automatic alternative to graphql#3687 that allows us to continue using ES6 features without perfomance lost.
This PR aims to explain what's going on for #3648 the main issues seem to be:
for..ofin hot pathsIf we find this to be sufficient we can find a way to add a build step or merge as-is with some lint-rules. This currently touches the following issues in hot-paths only.
There are more issues to be found. Other slowdowns could be due to raw ES6 classes, ....
EDIT: verifies yes, ES5 classes are a lot faster like these but imho it's not worth writing that as opposed to the little change of avoiding
for..ofin hot paths 😅I have a suspicion that the custom extension of Map (AccumulatorMap) is also to blame as it lives on the hot-path
Preliminary results where local is ES5 and the other is this branch. (some benches don't run when I use ES5 in tsconfig)