-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
[2.5.0] Lint runs are ~30% slower #1132
Comments
I can confirm this issue. For my codebase (Node.js backend app) the linting time jumped in the CI (the exact same VM sizes) from ~1:45 to 2:25 after updating from v2.4.0 to v2.5.0. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I havn't been able to reproduce the OOM errors but did get some better timing data in #1134 |
I just checked out your |
the alpha.3 commit was adding support for I have not looked further into this yet. I'll be sure to explicitly comment back here with updates to save you having to track and test each releases. |
Just in case you need more cases, I made measurements on different
If you need more info on our cases - please let me know. |
Same in our big (also proprietary) codebase:
edit: turns out I had caching enabled for v2.3 and actually it takes the same slow time. I think my problem is unrelated, opened another issue #1140 |
in our case it is 87% slower than with 2.3... DATA
Before:
After:
If you need more data please ping me. Thx! |
2.6.1: 374.75s similar results. i'm on a very large code base. |
Our time has jumped from 50s on version 2.4.0 to 350s on 2.6.1. (with Edit: With 2.7.0 this is back down to 63s. Thanks! |
If any one can verify #1179 ? Just do it according to this comment. |
Excellent @yoyo930021 ! I originally reported this SR and have just been testing #1179 with my production repository. It looks very good and it seems as we are back to the original performance in 2.3.3. I linted my 712 files 3 times with the following averages: 2.3.3: 118 secs |
Spinning off of discussion in #1126.
Reported by: @doberkofler
I think that this is because of the change in #1083
There are use cases like Vue, or Markdown, wherein we get provided N distinct content strings for the same filename, where N is the number of
<script>
tags in the vue file, or the number of code blocks in a markdown file.We used to not trigger a program sync if we hadn't been asked to parse the file yet, but for these use cases, the file contents TS reads are always different to the file contents eslint gives us, so we have to trigger a file sync on the first parse for a file.
I'll need to look at a solution for this, as invalidating the program for every single file in a CLI run for pure JS/TS codebases (when the file contents from eslint === the file contents in ts) is pretty silly.
The text was updated successfully, but these errors were encountered: