-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
⚡ Performance: parserOptions.projectService sometimes no longer outperforms parserOptions.project #9571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks to a very helpful pairing with @jakebailey, I filed
Those seem to be most of the performance discrepancy. ⚡
|
Removing from the v8 milestone. There are multiple issues filed over on TypeScript and our usage in community projects (e.g. t3-oss/create-t3-app#1936, trpc/trpc#5868) has shown real-world cases tend to be at least as fast. |
Status update: microsoft/TypeScript#59335 resolved something like >60-70% of the discrepency. From microsoft/TypeScript#59689:
|
I'm on
I checked the Performance document, but we don't have reloads. |
I notice, that when we added |
Oh! Sorry @oriSomething I missed your message. Without an actual reproduction it's hard to help. The normal steps we recommend are:
In general, if you have get partial results that aren't already noted in this issue, it can be helpful to post them. But something we can look at ourselves is really the best thing. |
I can understand if you can't help more than this. Thanks for your time! |
@oriSomething we have the same problem. Changing:
to:
increases ESLint's run time from 1m17s to 1m46s. |
@olegafx If it wasn't clear. |
That’s exactly what I said. Using |
@olegafx I'm so sorry. I miss read 🙈 |
Uh oh!
There was an error while loading. Please reload this page.
Overview
When we first started working with the new
parserOptions.projectService
(formerlyparserOptions.EXPERIMENTAL_useProjectService
), it outperformed equivalentparserOptions.project
setups by ~10-15%. We still sometimes have users report to us that it improved their linting speed. trpc/trpc#5868 is an example of one observation I've made.However, at some point since then, we've started to notice worse performance of
parserOptions.projectService
in our own measurements. https://github.com/typescript-eslint/performance contains tooling to test this. From https://github.com/typescript-eslint/performance/blob/45f77c00c6d4384d466c39e8eb633a76f33dd019/README.md#results:Summarizing those results, there seem to be two areas of slowness. Comparing
project
toprojectService
at ~1024 files:(even)
), jumping from ~2.35s to ~3.13s(references)
): jumping from ~2.4s to ~4.0sAlso note that
parserOptions.project
has been in production for years, with many performance optimizations around it.parserOptions.projectService
is very new and not yet stable. There is likely much more "low-hanging fruit" to optimize aroundparserOptions.projectService
.We don't yet know whether this is an issue in TypeScript or typescript-eslint. It's probably typescript-eslint.
Relevant past issues:
Node.getChildren
speed regression in ts 5.5 when used at very large scale microsoft/TypeScript#59101The text was updated successfully, but these errors were encountered: