Repository: TypeScript
Issue: [Performance] Add option for parser to compute Node.loc eagerly during parsing
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

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

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->
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 (https://github.com/typescript-eslint/typescript-eslint/pull/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](https://github.com/microsoft/TypeScript/files/10845401/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.