-
-
Notifications
You must be signed in to change notification settings - Fork 48
Parsing Svelte files with types is slow, and slows down more as more files are added to project #1084
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
Thank you! This is a great REPL, and I was able to reproduce the issue. I’ll take some time to investigate it soon. |
i had a quick look at this one thing to note is that this block of code: will create a new program for every file. TSESLint will realise there's no program or service, and create one under the hood. so maybe there is some saving to be had by reusing a project/program somewhere in the parser similarly, we actually parse nothing (but still create a program) in order to detect if something is TSESLint: this could probably just use |
@baseballyama I've updated my repro repository at mcous/eslint-svelte-ts-perf to get sveltejs/svelte-eslint-parser#704, which has sped up I dug in a little further into the items that @43081j was able to find:
Happily, it looks like this code path is a fallback that doesn't typically get hit. The suggestion is definitely correct though
From watching TSESLint's debug log, I'm not sure it's creating a new program for every file. It seems like it might be correctly re-using the program. However, I do see some suspicious logs that make me think there could be problem caused by the file contents on disk that the TS program reads do not match the file contents we pass to the TSESLint parser. I wonder if a custom TS program is needed that overrides the file read method, similar to how the Svelte Language Server works |
its been a while, but from what i remember, i did observe it making a new program every time (by debugging it, not by viewing logs). things may have changed since, though. it'd be easy to check by putting a breakpoint inside TSESLint where it creates the program |
@43081j I can confirm that it still creates new program for each This behavior can be observed in stdout as something like that:
|
Uh oh!
There was an error while loading. Please reload this page.
Before You File a Bug Report Please Confirm You Have Done The Following...
What version of ESLint are you using?
9.21.0
What version of
eslint-plugin-svelte
are you using?3.0.0-next.18
What did you do?
Configuration
What did you expect to happen?
With type-checking enabled, and without any lint rules enabled, linting a Svelte file should take about the same amount of time as linting a TypeScript file. Lint times should be roughly on par with type-checking times.
What actually happened?
When types are enabled, the linting time of Svelte components increases dramatically as the number of files in the project (Svelte or otherwise) increase. This occurs with both
projectService: true
andproject: './tsconfig.json'
. This lint increase occurs even if the ESLint config doesn't enable any rules. The performance issue appears to happen during the parse stage.In a simple project with 1000 Svelte files and 1000 TS files, and the ESLint config above (parsers configured, no rules enabled), my type-checking / lint times are:
svelte-check
)projectService
projectService
45 seconds20 seconds (see sveltejs/svelte-eslint-parser#704)project
In a closed-source real-life project that I work on, linting our TS files takes under a minute, while linting the Svelte files takes 5 to 8 minutes depending on the machine.
Link to GitHub Repo with Minimal Reproducible Example
I've created a reproduction repository with a few simple ESLint configs that configure the TS and Svelte parsers and nothing else, along with a script to create fixture components and modules:
https://github.com/mcous/eslint-svelte-ts-perf
Additional comments
Thanks for all your work on this project! I'm very happy to dedicate time and energy to investigating this issue further, but I'd need some guidance to do so.
I think this issue may be related to #954
The text was updated successfully, but these errors were encountered: