🐛 Biome cpu spinning forverr on save, suspected sluggish organizeImports behaviour

[jpike88]

Environment information

CLI:
  Version:                      1.0.0
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v16.14.2"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/8.5.0"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           true
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Workspace:
  Open Documents:               0

Discovering running Biome servers...

Incompatible Biome Server: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ℹ Rage discovered this running server using an incompatible version of Biome.

Server:
  Version:                      12.1.3

Incompatible Biome Server: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ℹ Rage discovered this running server using an incompatible version of Biome.

Server:
  Version:                      <=10.0.0

Server:
  Status:                       stopped

What happened?

1. pull down this repo and npm install: https://github.com/jpike88/biome-slow
2. open the code workspace in root directory
3. tweak something in eventDefinitions.ts, hit save.
4. observe as it's stuck saving, and biome maxes out cpu indefinitely

this problem happened in Rome as well, it's same as rome/tools#4757

Expected result

it should just work

Code of Conduct

• I agree to follow Biome's Code of Conduct

[ematipico]

Thank you for reporting. Can you disable the linter and let us know if you still have the issue?

[jpike88]

disabling linter saved instantly. having organize "source.organizeImports.biome": true was the culprit, it's definitely biome

[KaHLK]

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.

biome rage output

[ematipico]

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

[ematipico]

I am trying the repository provided, and I am seeing different results. When I disable only the import sorting and run biome check --apply, the command takes up to 5 seconds. Running the check alone is fast enough.

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.

[ematipico]

The rule noUselessConstructor is the one that is taking a lot of time. I disabled it and now the check --apply command is snappy.

[jpike88]

weird, cause I had noUselessConstructor set to off in my biome.json

[Conaclos]

This is strange because the code fix of noUselessConstructor is really simple.

[Conaclos]

However, you are right, something is going wrong with the rule. It is maybe unrelated to this issue.

[ematipico]

@jpike88 @KaHLK for the time being you can turn off the noUselessConstructor rule.

[jpike88]

Ok but I never had it turned on in my case, seems I already respect that rule anyway ;D

[ematipico]

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/

[KaHLK]

It's still a bit weird that I encountered the exact same behaviour back in [email protected] where noUselessConstructor was not yet enabled as a recommended rule (at least if I understand correctly).
At least based on the assumption that it is the same issue as experienced here.

It does however seem to be mostly mitigated by setting noUselessContstructor to off. Though I still sometime experience it slowing down a lot, with organizeImports on.

[ematipico]

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 noUselessContstructor

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.

It does however seem to be mostly mitigated by setting noUselessContstructor to off. Though I still sometime experience it slowing down a lot, with organizeImports on.

Which make sense. organizeImports uses the same engine to create the new content.

[KaHLK]

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 noUselessContstructor

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.

It does however seem to be mostly mitigated by setting noUselessContstructor to off. Though I still sometime experience it slowing down a lot, with organizeImports on.

Which make sense. organizeImports uses the same engine to create the new content.

Makes sense 😄 Thanks for the fast response and great explanation 👍

[jpike88]

organizeImports uses the same engine to create the new content

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.

[yckbilly1929]

also facing similar issue
I'm working on a medium-size in-house project, after upgrading to version 1.2.2
biome check --apply-unsafe hangs forever

[ematipico]

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.

[jpike88]

for what it's worth, still a problem on v1.3.3 with that initial repo I provided.... any closer to figuring it out?

[ematipico]

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?

[jpike88]

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