[2.5.0] Lint runs are ~30% slower

[bradzacher]

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.

[merlinnot]

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.

[Toxicable]

I havn't been able to reproduce the OOM errors but did get some better timing data in #1134
To summarise we've seen our eslint times go from 56s in 2.3.3 to 4.14m in 2.5.0

[doberkofler]

I just checked out your 2.5.1-alpha.3 and from a performance perspective there does not seem to be any change. Compared to 2.3.3 it is still about 30% slower.

[bradzacher]

the alpha.3 commit was adding support for declare class properties to unblock the prettier release.

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.

[luixo]

Just in case you need more cases, I made measurements on different @typescript-eslint/eslint-plugin versions (also changed @typescript-eslint/eslint-plugin-tslint and @typescript-eslint/parser versions)
On our big (unfortunately, proprietary) codebase:

On 2.1.0: 1m40.139s
On 2.3.0: 1m48.037s
On 2.5.0: 5m3.696s
On 2.5.1-alpha.3: 5m3.067s

If you need more info on our cases - please let me know.

[mpgon]

Same in our big (also proprietary) codebase:

2.3.0: 52.68s
2.5.0: 3m30.83s

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

[Hotell]

in our case it is 87% slower than with 2.3...

DATA

• files count: ts/js/jsx files count : 2760
• command run: yarn eslint --ext .js,.ts,.tsx --format codeframe our/company/codebase

Before:

• used typescript-eslint 2.3
• base tsconfig.json which didn't have all files within includes
• we used eslint hack createDefaultProgram: true
• lint time: 169.72s

After:

• used typescript-eslint 2.5
• created eslint.tsconfig.json which has all files within includes
• lint time: 1483.11s

If you need more data please ping me. Thx!

[kelly-tock]

$ npx eslint --cache --cache-location ./.eslint-cache -c .eslintrc.js --no-eslintrc --max-warnings 0 'src/js/**/*.{ts,tsx,js,jsx}' '../shared/src/js/**/*.{ts,tsx,js,jsx}'

2.6.1: 374.75s
2.3.3: 45.13s

similar results. i'm on a very large code base.

[ArkadyDR]

Our time has jumped from 50s on version 2.4.0 to 350s on 2.6.1. (with @typescript-eslint/recommended-requiring-type-checking, it's ~3 minutes less without). We have a very large code base.

Edit: With 2.7.0 this is back down to 63s. Thanks!

[yoyo930021]

If any one can verify #1179 ?

Just do it according to this comment.
#883 (comment)

[doberkofler]

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
2.4.0: hung
2.5.0: 3016 secs
2.6.1: 161 secs
#1179: 112 secs