Modified parse node definitions so they are all "monomorphic" (the sa… #8371
Conversation
…me fields with the same layout). This helps the V8 engine optimize performance.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
|
You mentioned elsewhere you weren't seeing quite the same speed improvement results as in microsoft/TypeScript#58928. One thing to note is that @dragomirtitian actually made three broader changes in that PR, and managed to untangle them into 3 separate PRs:
According to microsoft/TypeScript#58928 (comment), the win in monomorphizing types was the best one. From this PR, it looks like you mostly changed syntax nodes. If you're seeing a ~5% improvement on average that probably checks out, though there might be other factors at play here too. |
|
@DanielRosenwasser, thanks for the additional info. I didn't realize that the changes in typescript went beyond syntax nodes. Yes, I suspect that making the type objects monomorphic will have a bigger impact than the parse nodes. It's a heavier lift to make that change, but it could be worth it. |
| delete analyzerNode.scope; | ||
| delete analyzerNode.declaration; | ||
| delete analyzerNode.flowNode; | ||
| delete analyzerNode.afterFlowNode; | ||
| delete analyzerNode.fileInfo; | ||
| delete analyzerNode.codeFlowExpressions; | ||
| delete analyzerNode.codeFlowComplexity; | ||
| delete analyzerNode.dunderAllInfo; | ||
| delete analyzerNode.typeParameterSymbol; |
There was a problem hiding this comment.
This categorically deoptimizes the internal maps. If possible set them to undefined instead.
…me fields with the same layout). This helps the V8 engine optimize performance.