Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

performance, parser, node location, loc

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Currently TS does not compute or store a node's loc during a parse.
For TS itself this is fine because it's rarer that TS needs this information (I don't know for sure, but I'd say it only needs it when reporting errors?).
For @typescript-eslint, however, we need to compute the location because ESLint uses it for various things.

The issue is that computing the loc after the parse cycle means that TS has to do a binary search on the line/range table to compute the line/col of each of the start/end - which is obviously not super cheap to do.

As an alternative approach I tried changing ts-eslint's parser to lazily compute the locaction (typescript-eslint/typescript-eslint#6542). Sadly it was a net-neutral change because (I believe) the cost of defining a getter/setter is much more expensive than a property.
Unfortunately based on the way the ESLint's AST is designed we can't introduce a getLoc function, and can only defer this by using accessors.

Here is a cpu profile to help illustrate the cost - NON_LAZY_1.cpuprofile.zip. If you load this into https://speedscope.app you can use the search to find SourceFileObject.getLineAndCharacterOfPosition. It shows that the total time spent in SourceFileObject.getLineAndCharacterOfPosition for the parse was ~260ms (0.61% of the type-aware lint run).

You people know TS's parser better than I - so you're more aware of whether or not it's feasible to compute the loc up front without a binary search or not. If it's not - then we can just close this out as non-actionable.