Repo: investigate switching core TS->ESTree conversion logic from a "switch/case" to a "jump table" for performance improvements #6149
Labels
accepting prs
Go ahead, send a pull request that resolves this issue
performance
Issues regarding performance
repo maintenance
things to do with maintenance of the repo, and not with code/docs
Suggestion
https://artemis.sh/2022/08/07/emulating-calculators-fast-in-js.html
I read this a while ago but didn't think about it's possible performance application in our parser.
Our core conversion logic is one massive switch/case (currently 159 cases).
According to the stackoverflow comment (which has references to the v8 source code) - if you've got more than 128 cases then the switch might not get properly optimised and thus acts slower than hand-written if/else.
One workaround is to use a "jump table" instead of a switch. Jump tables rely on the case value instead being the key of an object - meaning the lookup is instead always as performant as a property lookup (which is usually O(1)).
We should investigate if switching to a "jump table" improves the perf of our parser.
For reference the conversion would be something like this:
For this task we'll want to:
typescript-estree
to measure the performance baseline with the current code.The text was updated successfully, but these errors were encountered: