Extension chokes on large files

[GabenGar]

VS Code version

1.93.1

Extension version

2.3.0

Biome version

1.8.3

Operating system

• [X] Windows
• [ ] macOS
• [ ] Linux

Description

Formatting takes forever, which pretty much makes extension non-responsive, i.e. it has a constant high processor usage with no results. When trying to kill biome.js which seems to be stuck on something it will relaunch itself. Or when trying to relaunch LSP server from VSCode command prompt it will error out about Restarting client failed or Biome client: couldn't create connection to server., thus requiring a full VSCode relaunch, only for the same thing to happen again.

Steps to reproduce

1. git clone https://github.com/GabenGar/repros.git
2. cd repros/biomejs/extension-formatter-large-files-chug
3. npm install
4. code .
5. Open src/main.js and format it from the context menu
6. Observe high CPU usage and no results and therefore close the IDE
7. Run formatter from CLI npx biome format ./src/main.js with the same problem. It will say that it did format in under 2 seconds after finishing for clearly more than 2 seconds.
8. Run prettier from CLI npx prettier format ./src/main.js. It will take more than 2 seconds but less than biome formatter.
9. Run formatter but with in-place rewrite npx biome format --write ./src/main.js. This will be lightning fast, which makes me think the base formatter command is a suspect and it degrades the entire extension. Although linter invoked as npx biome lint ./src/main.js is pretty fast too, but opening said file in VSCode will spike CPU usage from extension even before formatting.

Expected behavior

Not taking forever to format (prettier extension legit does it faster with less resource usage) and allow to restart LSP server without restarting the whole IDE if things go down south.

Does this issue occur when using the CLI directly?

Yes

Link to a minimal reproduction

https://github.com/GabenGar/repros/tree/main/biomejs/extension-formatter-large-files-chug

Logs

No response

[nhedger]

Thanks for the minimal repro, I'll take a look.

[nhedger]

I don't think this is an issue with the extension. However, I do believe there is another issue at play. Let me explain my theory.

When opening the file in VS Code

Opening the file in VS Code triggers the LSP and causes the CPU to spike. This is most likely due to the LSP trying to provide diagnostics for the file, and there are more than 1k diagnostics.

When formatting on the CLI

Running biome format src/main.js causes Biome to compute and print the difference between the file's current state and the desired state. I suspect that computing this difference and outputting it causes the slowdown.

Actually, running with the --write flag formats the file in under 250ms. That's because we're not computing or printing the diff.

Here's a little benchmark:

• time biome format src/main.js: 69.40s user 0.18s system 98% cpu 1:10.32 total
• time biome format src/main.js --write: 0.23s user 0.02s system 99% cpu 0.250 total

[GabenGar]

It's 50/50 in regards the fault, this specific problem might be caused by the underlying library being too slow, but the debugging process is definitely an extension problem. At the very least it should regard the restart command as absolute and interrupt all current tasks asap. In case "asap" is too slow, show a notification that it is in fact restarting the server. And if the server process got unexpectedly closed (aka killed manually) show the notification that it was closed unexpectedly with an action to restart instead of automatically restarting it. Although I remember having startup problems with Rome/Biome extension in the past, the current behaviour might be a bugfix of that.