-
Notifications
You must be signed in to change notification settings - Fork 238
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
Rules run a lot slower now #1274
Comments
Can you provide some more details about your setup, including the version of node,
Also while your numbers are pretty huge compared to what I was getting in #1187, they still look relatively consistent so suspect that's because of an external factor and impacts all your rules. |
Hi, I don't think it's likely that it's related to my setup. As an example, if you point it at the typescript compiler source, it pins the cpu to 100% for at least 15 minutes (I cut it off, not sure how much longer it would have taken). I'm not sure how much of that is eslint internals vs this specific plugin, but it seems like a lot. Every time I pause the debugger, it's executing code in https://github.com/microsoft/TypeScript/blob/main/lib/typescript.js
|
For me attempting to lint the TypeScript codebase results in a OOM, so could you try against the For me doing that with this config:
with this command:
Gives:
(this is running on Ubuntu 20.04 via WSL on Windows 11) My results are an order of magnitude faster than what you're reporting but it does depend on the size of the codebase, and that is still slower than what I originally had in #1187 so I'll have a quick look into that; however as I said in my previous comment the work we're doing is critical path stuff that afaik can't be optimized further without reducing accuracy, and it should still be about the same speed as most other plugins/rules. |
hmm I can't seem to get anywhere close to the sub 50ms results I posted in #1187, but I've done some flamegraphing and re-reviewed the code yet again and confirmed there's no further easy optimization wins; I wish we didn't have to have this performance hit, but overall I think it's reasonable given we're still under 30-60 seconds when running on a codebase the size of Jest. I'm happy if someone wants to try and dig into this themselves, in case there is an optimization I've missed, and happy to continue exploring a bit further to find out why the numbers you've reported @SLKnutson are in the thousands instead of the hundreds like mine, but otherwise this issue is probably going to be inactionable. |
Here is what I got for the jest repo (with some variance):
I took a quick look at the code. Recursively searching the scope is a heavy operation regardless, but I bet that doing the checks while recursing instead of building up the 2 sets and a map would give a nice performance lift without requiring heavy refactoring. |
Cool, that matches what I got so I think you're seeing the expected performance on whatever project your first results were from.
Could you expand on what you mean by that? We might be able to break out of the loop a bit early in some situations, but that would greatly depend on the structure of the code being linted; anything else I expect would require a heavy refactor, and again I want to stress that these times imo are very acceptable - you've said that the rules are slower now compared to before, but not said if that's an actual crippling problem or given any times that indicate it is. |
Ok I think I've got something😄 will have a PR up shortly, thanks @SLKnutson! |
@G-Rath Thanks! |
Yeah I was just trying that, but there's very little gain to be had (since its only called by two rules and usually always to always recurse through everything because of what its trying to figure out) so am going to leave that one as is for now. |
In my actual project, the eslint-plugin-jest time went from 116 seconds to 15 seconds 👍 |
What's that, 7.5x improvement? Nice! |
Hi,
I've noticed that recently this plugin has gotten a lot slower. I use many eslint rules, and still this plugin is over 50% of the runtime. It looks like it spends the majority of its time in
parseJestFnCall
.Here is a sampling of the output from TIMING=all
Thanks!
The text was updated successfully, but these errors were encountered: