Huge thanks to @SLKnutson for pointing this out - this is mainly a win for larger codebases, since we still have to loop until we find the information we need (or don't), but it is definitely faster

Before, completed in ~30 seconds:

Rule                            | Time (ms) | Relative
:-------------------------------|----------:|--------:
jest/consistent-test-it         |   919.565 |     5.3%
jest/prefer-expect-assertions   |   714.352 |     4.1%
jest/no-conditional-expect      |   626.779 |     3.6%
jest/no-standalone-expect       |   612.223 |     3.5%
jest/prefer-lowercase-title     |   608.857 |     3.5%
jest/no-identical-title         |   599.639 |     3.4%
jest/no-disabled-tests          |   587.099 |     3.4%
jest/prefer-each                |   586.834 |     3.4%
jest/prefer-snapshot-hint       |   585.044 |     3.4%
jest/require-top-level-describe |   579.505 |     3.3%

After, completed in ~15 seconds:

Rule                            | Time (ms) | Relative
:-------------------------------|----------:|--------:
jest/consistent-test-it         |   370.588 |     6.8%
jest/prefer-expect-assertions   |   248.168 |     4.6%
jest/expect-expect              |   232.857 |     4.3%
jest/no-standalone-expect       |   209.712 |     3.9%
jest/no-conditional-expect      |   193.040 |     3.6%
jest/no-disabled-tests          |   173.617 |     3.2%
jest/no-identical-title         |   167.683 |     3.1%
jest/prefer-snapshot-hint       |   161.561 |     3.0%
jest/require-top-level-describe |   159.859 |     3.0%
jest/prefer-each                |   159.230 |     2.9%

Resolves #1274

Woah, surprised by the big difference! Great job 👍

Based on percentages, 17.4 seconds vs 5.4 seconds for the actual rules running. The extra time in the full runtime is eslint internals. Nice!

I just tried the same optimization to scopeHasLocalReference but it doesn't result in any noticeable win so am going to land this as-is; that makes sense anyway because what we're doing there actually requires us most of the time to recuse through everything, and it's only used by two rules 🤷

@G-Rath

It might be possible to improve this even more. There is a set field on Scope that I think has a map from variable name => variable, so each level check can use that instead of iterating the variables. When I swapped it out for my project, I got the same result as the existing implementation, but I'm not 100% sure that it works in all scenarios. If it can be used, the performance should be even better. Also, it can probably be used in scopeHasLocalReference too.
Thanks!

const resolveScope = (scope, identifier) => {
  let currentScope = scope;
  while (currentScope !== null) {
    const ref = currentScope.set.get(identifier);
    if (ref && ref.defs.length !== 0) {
      const importDetails = describePossibleImportDef(ref.defs[ref.defs.length - 1]);
      return importDetails?.local === identifier ?  importDetails : 'local';
    }
    currentScope = currentScope.upper;
  }
  return null;
};

@SLKnutson neat, but for me that doesn't give any noticeable improvements on the performance so I think it's not worth switching just to save a line of code.

btw @SLKnutson if you wouldn't mind, I would be interested in seeing what the difference is if you are/are not using @jest/globals, since that should trigger slightly different code paths that I think would make a difference. (i.e. if your project is using @jest/globals, switching to using the native globals, and vice versa)

fwiw I've also tried caching resolving things at each level of scope, which also made no significant difference.

@G-Rath
I haven't tried the global stuff yet, but with the change I mentioned above to resolveScope, I got these speed-ups before/after. Seems like it cuts most rule run times by a factor of 2 or 3, which is noticeable for bigger projects. Thanks!