Applying Code in Cursor is 50x Slower than Before

TL;DR

Noticed a high error rate and significant slowdown (50x slower than before) in Cursor’s ‘code apply process’. Observed high GPU usage (90% under Copy), minimal VRAM and CUDA involvement, and loud fan noise. Restarting the app and system had no effect. Suspect inefficient use of local resources by the small local model.


Issue

Recently, I’ve been facing significant performance issues with Cursor that I believe warrant further clarification and potential solutions.

Cursor seems to use a small local language model to execute this feature, parsing the output from an LLM to the file being edited. However, I am not entirely sure if this model runs locally or if there is another underlying process involved.

At first, I began to notice a higher-than-usual error rate from the small local model that Cursor uses for interpreting and parsing LLM output. This model plays a crucial role by processing the output from the primary LLM and applying code changes. Following this initial issue, the code application process itself started to slow down dramatically, running nearly ten times slower than what I’ve previously experienced, which has greatly affected my workflow.

Soon after, I observed that my computer’s fan began to spin loudly whenever the ‘apply code’ phase was running, suggesting a considerable increase in resource consumption. To understand the cause, I checked the Task Manager and saw that GPU usage spiked significantly, reaching up to 88% under Copy processing. Surprisingly, despite this high usage, VRAM and CUDA processing remained minimal, which pointed to an inefficient utilization of the available GPU resources. This pattern raised questions about the underlying implementation of the local model and how it manages hardware resources during these operations.

Troubleshooting Attempts

  • Application Restart: I restarted the Cursor application, but this did not resolve the problem.
  • System Reboot: Restarting the computer also had no impact on the issue.

Seeking Clarification

  • Expected Behavior: Is it normal for Cursor’s local language model to exhibit such high GPU usage with minimal VRAM and CUDA involvement?
  • Potential Issues: Could this be a bug or an unintended effect introduced in recent updates?
  • Recommendations: Are there any known optimizations or solutions to prevent this high GPU load and improve overall performance?

Given that Cursor is a paid product, users should not need to deal with these kinds of development challenges. Ensuring an efficient and reliable user experience is crucial. Any feedback or acknowledgment from the team would be appreciated.

Screenshot for Reference

I’ve attached a screenshot showing the GPU usage spike and the specifics of Copy processing load during code application for further context.

@deanrie, Hi there! I wanted to see if you have any ideas or suggestions for tackling this issue.

Update:
It started to work correctly again without me doing anything. Not sure what happened.

2 Likes

I’m glad the problem is resolved.

@deanrie, it started to behave like that again. Any insights?

Did you get update 0.42.5? Also, check your logs:

@deanrie, Thank you for your reply. Yes, I got the latest update.

Version: 0.42.5
VSCode Version: 1.93.1
Commit: 001668006cc714afd397f4ef0d52862f5a095530
Date: 2024-11-14T00:33:36.512Z
Electron: 30.4.0
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

I will go through the logs to see if I can find any clues. I don’t understand why I have this massive GPU load when I experience the issue.

@deanrie, I found something that might be related.

This is only a small excerpt. It seems to be a memory leak.

2024-11-16 12:44:45.104 [error] [5573] potential listener LEAK detected, having 2817 listeners already. MOST frequent listener (2814):: Error
    at m.create (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:433:58394)
    at J.q [as onWillDispose] (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:436:1100)
    at K.a (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:2559:50844)
    at K.h (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21630)
    at K.g (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21614)
2024-11-16 12:44:59.340 [error] [5573] potential listener LEAK detected, having 2905 listeners already. MOST frequent listener (2902):: Error
    at m.create (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:433:58394)
    at J.q [as onWillDispose] (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:436:1100)
    at K.a (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:2559:50844)
    at K.h (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21630)
    at K.g (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21614)
2024-11-16 12:45:11.622 [error] [5573] potential listener LEAK detected, having 2993 listeners already. MOST frequent listener (2990):: Error
    at m.create (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:433:58394)
    at J.q [as onWillDispose] (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:436:1100)
    at K.a (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:2559:50844)
    at K.h (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21630)
    at K.g (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21614)
2024-11-16 12:45:25.149 [error] [5573] potential listener LEAK detected, having 3081 listeners already. MOST frequent listener (3078):: Error
    at m.create (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:433:58394)
    at J.q [as onWillDispose] (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:436:1100)
    at K.a (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:2559:50844)
    at K.h (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21630)
    at K.g (vscode-file://vscode-app/c:/Users/gabri/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:498:21614)

...

2024-11-16 12:50:14.002 [info] Extension host (LocalProcess pid: 16000) is unresponsive.
2024-11-16 12:50:14.761 [info] Extension host (LocalProcess pid: 16000) is responsive.
2024-11-16 12:50:14.761 [info] UNRESPONSIVE extension host: received responsive event and cancelling profiling session
2024-11-16 12:50:14.762 [info] UNRESPONSIVE extension host: starting to profile NOW

Maybe an extension is using resources. Open the command palette and search for Developer: Open Process Explorer to see if you can identify it. Also, try starting in disable-extensions mode to check if the issue persists.

@deanrie, I will try that. :pray::pray::pray:

much faster than VsCode + Github Co-Pilot, terrible experience. I was trying it since I have it but Cursor just is the best :slight_smile:

I have the same logs - and it’s insane how slow Cursor got

Hey, what version of Cursor do you have at the moment?

Here are my version infos:

Version: 0.42.5
VSCode Version: 1.93.1
Commit: 001668006cc714afd397f4ef0d52862f5a095530
Date: 2024-11-14T00:33:36.512Z
Electron: 30.4.0
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.6.0

As the others, I experienced this with a growing codebase. I don’t know if there is anything to be done here but with more files in my workspace, also the wait always increased (as well as the errors/failures to apply changes).

Try updating by downloading the latest version from this page.

Sorry for the delay in providing a follow-up. After disabling all extensions (I had only the very basic ones) the issue went away. I have also updated Cursor since, so I can’t pinpoint the root cause accurately.

Thank you for your continued support.

1 Like