Huge `import/no-cycle` performance downgrade in 2.25.3

[zaicevas]

I upgraded eslint-plugin-import 2.22.1 -> 2.25.3 and the performance downgrade is huge. eslint is 7.24.0.

Roughly a hundred files:

Rule                                       |  Time (ms) | Relative
:------------------------------------------|-----------:|--------:
import/no-cycle                            | 304818.252 |    97.0%
prettier/prettier                          |   2347.669 |     0.7%
import/named                               |    754.553 |     0.2%

2.24.2 is fine:

Rule                                       | Time (ms) | Relative
:------------------------------------------|----------:|--------:
import/no-cycle                            |  4206.707 |    23.0%
prettier/prettier                          |  1914.555 |    10.5%
react/prefer-stateless-function            |   849.317 |     4.6%

[ljharb]

Thanks, that's quite large.

The only changes that touched ExportMap in that range are 9a744f7 and #2212.

Do you have a TypeScript codebase? Also, can you confirm that v2.25.4 (which contains #2341) has the same speed drop?

[zaicevas]

Do you have a TypeScript codebase?

Yes

can you confirm that v2.25.4 (which contains #2341) has the same speed drop?

Yes:

Rule                                          |  Time (ms) | Relative
:---------------------------------------------|-----------:|--------:
import/no-cycle                               | 300578.485 |    95.2%
prettier/prettier                             |   2384.299 |     0.8%
react/prefer-stateless-function               |    866.305 |     0.3%

[ljharb]

That strongly suggests it’s #2240. cc @mrmckeb

[mrmckeb]

Are you able to share a small reproduction of the issue @zaicevas? Or if not, can you share your tsconfig.json?

[zaicevas]

Are you able to share a small reproduction of the issue @zaicevas?

Sorry, won't be able to do that due to lack of time.

tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2016",
    "module": "commonjs",
    "jsx": "react-jsx",
    "noEmit": true,
    "strict": true,
    "noImplicitAny": false,
    "noImplicitThis": false,
    "baseUrl": "./app/",
    "esModuleInterop": true,
    "allowUnreachableCode": false,
    "isolatedModules": true
  },
  "include": [
    "./app/**/*.ts",
    "./app/**/*.tsx"
  ],
  "exclude": [
    "./node_modules/**/*"
  ]
}

[sadovnychyi]

Got 30s speedup (1:59s -> 1:29s for total linting time) by setting ignoreExternal to false.

-'import/no-cycle': [2, {ignoreExternal: true, maxDepth: 3}],
+'import/no-cycle': [2, {ignoreExternal: false, maxDepth: 3}],

[mrmckeb]

Thanks all, I did some quick testing around this today and can confirm that there is a massive performance downgrade between these releases.

Findings

The following are timings for import/cycle. This test project has 7 JavaScript and TypeScript files.

Version	New tsconfig resolution	Old tsconfig resolution
2.22.1	~80ms	~80ms
2.25.4	~235ms	~235ms

It seems that the issue is related to another change, @ljharb.

Methodology

1. Install the latest 2.25.4 alongside a fresh Next.js app.
2. Enable import/no-cycle and run TIMING=1 yarn eslint .
3. Copy this file in place of the version that shipped with 2.25.4.
   https://unpkg.com/eslint-plugin-import@2.22.1/lib/ExportMap.js
4. Modify the code (around line 705) to reimplement the new behaviour.

         // const jsonText = _fs2.default.readFileSync(tsConfigInfo.tsConfigPath).toString();
         // if (!parseConfigFileTextToJson) {
         //   var _require = require('typescript');
         //   parseConfigFileTextToJson = _require.parseConfigFileTextToJson;
         // }
         // const tsConfig = parseConfigFileTextToJson(tsConfigInfo.tsConfigPath, jsonText).config;
         // return tsConfig.compilerOptions.esModuleInterop;
   
         const ts = require('typescript');
         const path = require('path');
         const configFile = ts.readConfigFile(tsConfigInfo.tsConfigPath, ts.sys.readFile);
         const config = ts.parseJsonConfigFileContent(
           configFile.config,
           ts.sys,
           path.dirname(tsConfigInfo.tsConfigPath),
         );
         // So we don't have to make other changes in this file.
         config.compilerOptions = config.options;
         return config;

5. Do the same in reverse (reimplement old behaviour in new version).

[zaicevas]

2.22.1 -> 2.24.2 is also a significant performance downgrade:

2.22.1:

import/no-cycle                            | 15407.126 |     6.1%

2.24.2:

import/no-cycle                   | 70428.732 |    36.3%

[zaicevas]

It turns out that 2.24.2 does not report import/no-cycle violations at all 😕

// a.ts
import './b'

export function ab() {
  //
}

// b.ts
import { ab } from './a'

[DarkPurple141]

Keen to watch this issue, have noted this rule is eating into our CI, accounting for ~80% of our overall linting pipeline in a large-ish monorepo. I'm interested to know whether there is any thought on caching cycles previously searched across files to decrease the runtime performance hit of the rule.

[SDAdham]

same here, no-cycle seems to be a performance destroyer

[JounQin]

Can you try https://github.com/un-es/eslint-plugin-i to see whether it's much faster?

[SDAdham]

It didn't work:

yarn add -D eslint-plugin-import@npm:eslint-plugin-i
➤ YN0000: ┌ Resolution step
➤ YN0016: │ eslint-plugin-import@npm:eslint-plugin-i: Registry failed to return tag "eslint-plugin-i"
➤ YN0000: └ Completed in 3s 302ms
➤ YN0000: Failed with errors in 3s 305ms

[JounQin]

@SDAdham Sorry I don't use yarn@v2+, maybe you can find something similar to package aliasing.

---

https://yarnpkg.com/features/protocols/#table

So it seems eslint-plugin-import@npm:eslint-plugin-i@latest should do the trick.