-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Huge import/no-cycle
performance downgrade in 2.25.3
#2348
Comments
Yes
Yes:
|
Are you able to share a small reproduction of the issue @zaicevas? Or if not, can you share your |
Sorry, won't be able to do that due to lack of time.
|
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}], |
Thanks all, I did some quick testing around this today and can confirm that there is a massive performance downgrade between these releases. FindingsThe following are timings for
It seems that the issue is related to another change, @ljharb. Methodology
|
2.22.1 -> 2.24.2 is also a significant performance downgrade: 2.22.1:
2.24.2:
|
It turns out that
|
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. |
same here, no-cycle seems to be a performance destroyer |
Can you try https://github.com/un-es/eslint-plugin-i to see whether it's much faster? |
It didn't work:
|
@SDAdham Sorry I don't use https://yarnpkg.com/features/protocols/#table So it seems |
{
// rest of package.json
"resolutions": {
"eslint-plugin-import": "npm:eslint-plugin-i@latest"
}
} |
Maybe I'm doing something wrong, but I got exactly the same result. |
Same here unfortunately. I was quite excited for this fix and was able to use the yarn resolution field to force Before:
After:
|
Then it's not a resolving issue but performance effects in |
We have a large TS monorepo that takes around a half hour to lint using |
Anybody managed to solve this one? I just tried to add eslint to my repo for the first time ever and ran into this. Linting a single file takes 3+ minutes which is obviously not usable. edit: actually it takes 10 minutes for a single file haha
Setting |
Is this going to be fixed, or is there a workaround? |
@MayGo it will be fixed once there's a PR to fix it, and there's no workaround or else that would be the fix. |
Do we know if this issue exists on both npm and yarn, and if it exists on all versions of yarn? Or is there some other cases where it doesn't exist? |
@tnguyen42 npm or yarn should have no impact on it at all, since it's about runtime performance. It's not that it's been paid "so little attention", it's that performance issues are very hard to reproduce reliably, and without that, they're very hard to fix. |
We're also working in a monorepo, and we just updated to the new eslint version. The performance still seems to be a big issue -
|
I found out a couple of things:
// .eslintrc.js
module.exports = {
settings: {
'import/internal-regex': '^(@myNamespace/|client/|server/|shared/|__test__/|scripts/|types/)',
},
rules: {
'import/no-cycle': ['error', { ignoreExternal: true }]
},
// [other config...]
}
[1] Flamegraph overview: [2] [3] [4]
[5] [6] [7] [8] [9] |
It has to parse every file fully in order to know what it imports/exports (or requires/module.exports, for CJS). A half dozen rules depend on the export map - no-cycle is just one of them - but the map is cached across them, thankfully. This does mean that improvements in the export map benefit many rules at once. I think it would be perfectly reasonable to detect the presence of |
Wow thanks for the quick reaction!
Ok, I understand that. I thought that a "lightweight" import (which only scans for imports/exports/requires/module.exports) could be faster. What about the external files? E.g. there's no chance that
Yes, I noticed, and I checked for that immediately, because it would have been a low-hanging fruit.
Yep. I'm not convinced it would bring any benefits, but I'll try implementing it in the next couple of days. Do you have a good tip on how to do performance tests? I'm currently modifying the compiled version directly in my sample app directory, and I'm thinking there must be a better way... :) |
Unfortunately I don't :-/ usually i |
Actually I think it's the biggest issue here |
I can confirm this. We had |
I'd expect an "ignore" option to make things faster, not slower, so there must be some low-hanging fruit here - a PR would be welcome. |
Is there any solution or plan? The newest 2.27.5 still very slow. |
Also I can confirm. From 13 minutes to 2 min. |
Here's an idea for how to make |
Bumping this, it's a also a big problem in our (semi-large) monorepo, with |
Same issue here: with |
When #2998 is merged and released, this should improve drastically. |
@ljharb thanks for getting that merged! Any estimate when it could get released? I'm mostly asking since the last regular release was back in December, so it's hard to guess when the next one might come around. |
The maintainer is working on flat config support, so after it will be done, expect a minor version I think? |
@mrmckeb regarding previous conversation about your contribution: #2240 Resolving TypeScript config more correctly is a good change, but I'm curious if it could be a big contributor to filesystem accesses reported in profiling?
|
Hi @soryy708! As noted here, I did test this and found that it wasn't the cause of the significant performance impact noted in this thread. I could have missed something, but was confident at the time. I didn't go into profiling, so I'm not sure of the exact performance impact, but I remember it was very small, especially compared to the problem noted in this thread, which I could also reproduce on the release in the title. I think in-memory caching of the fully resolved/parsed config is a good idea. Putting extended configs behind a flag is probably the wrong solution here, especially as we don't know if it has caused any performance issues:
|
The SCC optimization has been released, try v |
I'm going to close this; if there's still a perf issue in v2.30+, please file a new issue. |
I upgraded
eslint-plugin-import
2.22.1 -> 2.25.3 and the performance downgrade is huge.eslint
is7.24.0
.Roughly a hundred files:
2.24.2
is fine:The text was updated successfully, but these errors were encountered: