Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[2.5.0] Lint runs are ~30% slower #1132
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
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.
@Toxicable - there should not have been any discernible changes to the memory usage with the new code, as the new code path should only be used during a long running lint session (i.e. IDE).
Please raise a new issue for out of memory error, and provide as much information as possible, including the output of a
Just in case you need more cases, I made measurements on different
If you need more info on our cases - please let me know.
in our case it is 87% slower than with 2.3...
If you need more data please ping me. Thx!
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