search

ambar / vscode-bundle-size

Display the bundle size of npm packages: https://marketplace.visualstudio.com/items?itemName=ambar.bundle-size
32 stars 1 forks source link

High CPU usage when using the extension MBP M1 PRO #20

Open lusqua opened 1 month ago

lusqua commented 1 month ago

I encountered a significant issue with high CPU usage while using your extension. The problem became particularly noticeable after I started working on a large codebase ( 528.088 lines of code ) . Specifically, I noticed that my CPU usage spiked to 95% when running ESLint. Upon further investigation using ps aux, I found that the esbuild process associated with your extension was consuming a large amount of CPU resources.

Here's the output from ps aux | grep esbuild:

lusqua      94803   0.0  0.0 410592976   1136 s004  R+    4:51PM   0:00.00 grep esbuild
lusqua      94733   0.0  4.7 411819248 782048   ??  S     4:51PM   0:04.96 /Users/lusqua/.vscode/extensions/ambar.bundle-size-1.8.0/node_modules/@esbuild/darwin-arm64/bin/esbuild --service=0.21.3 --ping

After disabling the extension, the CPU usage returned to normal. I am attaching a screenshot for your reference, where you can see the CPU usage spike (marked in red) and the normal CPU usage after disabling the extension (marked in green).

image

System Info:

Given the hardware I am using, such high CPU usage shouldn't be happening. Please investigate this issue as it severely impacts performance.

Steps to Reproduce:

  1. Enable the extension in VSCode.
  2. Run ESLint or work in a project where the extension is active.
  3. Monitor CPU usage.

Expected Behavior: CPU usage should remain at a reasonable level without causing performance issues.

Actual Behavior: CPU usage spikes to 95%, causing significant slowdowns.

Attachment:

Thank you for looking into this issue. Please let me know if you need any further information.

d4vz commented 1 month ago

Having same issue... Fix it!

ambar commented 1 month ago

I think this is normal, esbuild's work is CPU-intensive and it will get the job done as fast as possible. The workload of the plugin doesn't affect the main VSCode process and UI, because VSCode uses a multi-process architecture where plugins run in separate processes.

One improvement I could make would be to make the computation on-demand, such as hovering or focusing on the corresponding reference statement to start the computation, which could take some time.

lusqua commented 1 month ago

I haven't seen the code, but isn't caching a good option?

ambar commented 4 weeks ago

@lusqua Caching is enabled by default (kept in memory, see the settings of bundleSize.cache) and each import is bundled only once.