High CPU and memory usage while editing queries

[Marcono1234]

Describe the bug The performance when just editing queries, not even compiling or running them yet, is not very good. I get high CPU usage (80% for a notebook with 6 cores / 12 processors, running at > 3 GHz), and high memory usage (> 4 GB just by the OpenJDK process of the extension). And this high CPU and memory usage can sometimes even last a few seconds after you made the last edit in the query source code.

It does not even have to be a complex query or query suite, I even get this for the sample "Hello world". Example:

https://github.com/user-attachments/assets/d5b5cf0c-b6a4-489e-9bfa-18bf3c167a39

Disabling Microsoft Defender Real-time protection did not seem to make a difference.

I know this comparison might not be fair since CodeQL is quite different from lots of other programming languages, but I haven't seen such performance problems with other programming languages or IDEs yet. For example in a Java project in IntelliJ memory usage is about 2 GB, and writing code might trigger some CPU usage spikes up to 40%, but only for a very short time.

Maybe related to #594?

Version (this is not a new problem, I think I have seen this for a few months already)

VS Code:

Version: 1.106.3 (user setup)
Commit: bf9252a2fb45be6893dd8870c0bf37e2e1766d61
Date: 2025-11-25T22:28:18.024Z
Electron: 37.7.0
ElectronBuildId: 12781156
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

CodeQL extension:

CodeQL extension version: 1.17.6 
CodeQL CLI version: 2.23.6 
Platform: win32 x64

To reproduce

1. Open a new empty folder in VS Code
2. Open the Windows Task Manager next to VS Code
3. Use the command "CodeQL: Create Query"
4. Select "Java" as language
5. Edit the generated example.ql, write some arbitrary CodeQL code at fairly decent speed :x: Issue: The extension (more specifically the corresponding "OpenJDK Platform binary" process) shows high CPU and memory usage

Expected behavior Performance while editing queries should be better

Additional context Not really sure, and I am really wondering why others have not reported this before. I don't think there is anything special about my setup, I have no custom CodeQL settings (other than controllerRepo), and as shown above this even occurs for the "Hello world" sample.

[nickrolfe]

Sorry about the delayed response, @Marcono1234.

This behaviour is not entirely unexpected. There are a few reasons for this:

1. Our optimisation efforts up to now have mostly focused on reducing latency, particularly on the time it takes to generate autocomplete suggestions, rather than on minimising CPU or memory usage.
2. Seeing CPU usage continue to spike for a few seconds after editing (or after the autocomplete suggestions are populated) is likely caused by error checking.
3. Even though you have a small query in your example, it also checks for errors in all the transitive imports from your import java statement, so there is quite a lot of library code to check.
4. Although some of the language-server actions that occur when you make a change are incremental, error checking is unfortunately not, so the language server is doing a full error-checking pass on every change.

There are potentially some improvements we could make here. Is your main concern just that the high CPU/memory usage is wasteful, or are you finding that your editing experience is slow/laggy?

[Marcono1234]

No problem for the deplay, and thanks for the explanation!

Is your main concern just that the high CPU/memory usage is wasteful, or are you finding that your editing experience is slow/laggy?

On an older device (slower, only 8 GB RAM and slower disk) I used for development before, it made editing queries rather unpleasant because it reached 100% CPU usage and ~90% memory usage (if I remember correctly). On the device I am using now for development (described above in the issue description) the experience is 'okayish' I guess. But I think at some point this high CPU usage also slows down autocompletion and error highlighting speed. Maybe because there is still a 'backlog' of pending error-checking while the CPU usage is that high.

Would it be possible to improve this at least to some extent by reducing the frequency at which this error-checking is done? Though this is probably only a workaround which reduces the effect, but does not properly address it.

[nickrolfe]

Thanks for the feedback. We're tracking these potential improvements internally, but I'm afraid I can't promise any particular timeframe in which we'll be able to implement them.