-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
[3.0.1] Huge performance regression in import/no-cycle #113
Comments
I will look into this! |
@sqal In the meantime, would you mind sharing the repo w/ me privately so that I can do some profiling? I didn't notice significant performance regression in a few of my repos. |
@SukkaW Hi. I am sorry but unfortunately can't share the code because it's company's repository. Regarding your benchmarks, are you saying that tests you have done with 3.0.1 are a little slower or actually faster? I am sorry I didn't mention it earlier, but I've just found that macOS:
Windows:
This is much, much better. Windows still runs slower :/ but what an improvement overall. 3.0.1 is still slower than 0.5.3 though 🤔 |
It means there must be some regression related to resolving and parsing. I will be looking into this! In the meantime, there is a resolver made by @9romise: https://github.com/9romise/eslint-import-resolver-oxc |
|
Thanks for the info! I will profile on the core-js repo then! |
Update: @zloirock @sqal I have successfully grabbed the flamegraph from core-js repo: For any one is also interested: flamegraph.html.txt |
I tried |
The problem might be caused by SCC. Calculating SCC introduces extra overhead, while it doesn't actually reduce any heavy works. Before completely removing SCC, I might try to optimize SCC first. |
Any news on no-cycle-next? Really interested to see how it performs |
We can't backport import-js#2998. It actually introduces an extra step (SCC doesn't replace the original detection algorithm, instead it is a new additional check) without introducing a proper early return. That's why it becomes slower and I have reverted it. I am interested in using https://www.npmjs.com/package/@newdash/graphlib to implement a dependency graph, this should be faster than the |
eslint-plugin-import merged changes to SCC and fixes to performance, so you may want to try porting it again, or comparing your performance to the original rule. Idk why would graphlib be faster than scc upstream uses? |
Your implementation is done by adding an early return, with an overhead for building up the SCC graph. If SCC does detect any cycle import, it immediately falls back to the original detection implementation, which doubles the work per file linted. So it'd be slower rather than faster.
I want to build a cycle import detection from the ground up. It would calculate SCC once per module and doesn't need any extra detection steps at all. You can't attach extra objects (E.g. AST) with |
Hi. Today I upgraded the plugin to version 3.0.1 and noticed a huge drop in performance in the no-cycle rule. Details below.
Setup
Depencecies:
Eslint config, I only left the no-cycle rule
I ran the test on these two machines.
macOS
Windows
Results:
MacOS:
Windows:
Summary
So these are the numbers. I ran the test on a fairly large TS codebase (~680 files). You can see that 3.0.1 is at least 3x slower on both machines, which is strange because this release was supposed to significantly improve no-cycle performance. What is also noteworthy to me are the test times on Windows compared to macOS with
eslint-plugin-import-x@0.5.3
, they're like ~2.5 times slower. I know both my pc's are old and rather slow, but Windows have slightly better cpu, it's also overclocked, so I don't understand why it's so slow there. But the times witheslint-plugin-import-x@3.0.1
on Windows are really bad, which worries me the most. I would appreciate your help with this issue and let me know if you need more info from me.The text was updated successfully, but these errors were encountered: