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.

Ourcore conversion logic is one massive switch/case (currently 159 cases).

According tothe 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:

switch(node.kind){caseSyntaxKind.SourceFile:// ...caseSyntaxKind.Block:// ...// ...}// toconstJUMP_TABLE={[SyntaxKind.SourceFile]:(node:ts.SourceFile)=>{/* ... */},[SyntaxKind.Block]:(node:ts.Block)=>{/* ... */},// ...};JUMP_TABLE[node.kind](node);

For this task we'll want to:

1. instrumenttypescript-estree to measure the performance baseline with the current code.
2. make the conversion to a jump table.
3. measure the performance after the change.
4. if (3) < (1), then merge the change.