-
-
Notifications
You must be signed in to change notification settings - Fork 504
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
🐛 Biome cpu spinning forverr on save, suspected sluggish organizeImports behaviour #98
Comments
Thank you for reporting. Can you disable the linter and let us know if you still have the issue? |
disabling linter saved instantly. having organize |
If I disable everything (organizeImports & linter), it doesn't cause the cpu to spin up. --- a/biome.json
+++ b/biome.json
@@ -3,6 +3,9 @@
"formatter": {
"enabled": false
},
+ "organizeImports": {
+ "enabled": false
+ },
"javascript": {
"formatter": {
"quoteStyle": "single",
@@ -13,7 +16,7 @@
}
},
"linter": {
- "enabled": true,
+ "enabled": false,
"rules": {
"complexity": {
"noExtraBooleanCast": "off", Re-enabling the linter and formatter, does not cause it to spin up cpu either. But re-enabling the organizeImports causes the cpu to spin up again. |
Amazing, thank you for the detailed report. If we're able to identify the code that causes the issue, we can fix the issue real quick |
I am trying the repository provided, and I am seeing different results. When I disable only the import sorting and run This means that the cause of the issue is not the import sorting but the linter where some recommended rule applies a safe action that takes a long time. I also tried to keep only the imports from the code, and the import sorting is snappy. @Conaclos, this is a severe regression that we have to investigate ASAP. |
The rule |
weird, cause I had |
This is strange because the code fix of |
However, you are right, something is going wrong with the rule. It is maybe unrelated to this issue. |
Ok but I never had it turned on in my case, seems I already respect that rule anyway ;D |
It's part of the recommended rules: https://biomejs.dev/linter/rules/no-useless-constructor/ |
It's still a bit weird that I encountered the exact same behaviour back in It does however seem to be mostly mitigated by setting |
The origin of the issue for that particular code is given by that rule, but the underlying issue is not the rule itself but how we process the code fixes. This gets big when you have a big file with a certain number of code fixes. In this particular case, the file goes under many fixes triggered by It's an issue we know of, but the fix requires some time to get right. I want to keep the issue open because this kind of performance regression should not happen.
Which make sense. |
Makes sense 😄 Thanks for the fast response and great explanation 👍 |
Ok now I get it. I had noUselessConstructor explicitly turned off on purpose to replicate my eslint settings from the beginning, and perceived the issue from toggling organizeImports. |
also facing similar issue |
To whoever comes here, it's important to share a snippet that triggers the problem. Without that, we are basically useless and we can't help you. |
for what it's worth, still a problem on v1.3.3 with that initial repo I provided.... any closer to figuring it out? |
I did triage your issue a time ago, and I managed to reduce the problem to a single file. I ran biome check on that file yesterday and I didn't find any performance issues. Are you able to provide more information that we have logging now? |
I'm a dummy, 1.3.3 actually works fine! I forgot we moved back cause of #639. I'll close this one as solved for me |
Environment information
What happened?
this problem happened in Rome as well, it's same as rome/tools#4757
Expected result
it should just work
Code of Conduct
The text was updated successfully, but these errors were encountered: