AL
AL copied to clipboard
microsoft
AL Extension Memory Leak
1. Describe the bug
The AL Language Extension consumes large amounts of memory and considerable CPU resources.
Especially the memory consumption confuses me, since none of the sub-processes add up to the total. Is this a memory leak issue?
2. To Reproduce The workspace contains around 1.500 files.
3. Expected behavior
4. Actual behavior
5. Versions:
- AL Language: v9.0.615906
- Visual Studio Code: 1.67.1
- Business Central: Platform 20.0.37114.38150 + Application 20.0.37253.38230
- List of Visual Studio Code extensions that you have installed:
Do you have a sample workspace that reproduces the issue? We should look into this, but it will be easier if we have a consistent repro to work off.
The example workspace would be our ISV solution, which I cannot make public for obvious reasons. But opening the Base Application source does basically the same thing.
Is the issue with memory usage in general, or is there a clear growth pattern?
If the case is that there's constant memory growth over time that doesn't stabilize, then we have a clear leak. If this is the case, if you can narrow it down to at least some actions (i.e. compiling, debugging) when memory usage increases but does not decrease, that would really help.
If the case is that the memory usage is high, that's more difficult and out of scope for this repo. We're always trying to improve our resource consumption, but it's an ongoing effort and not one that we can handle in the scope of a github issue.
From my observation, it's everything that has to do with syntax highlighting, navigation and code actions.
- Opening a new .al file
- Go to definition
- Find references
- Intellisense
- Renaming variables
The longer you are active within the workspace the more memory is consumed, but never freed up again. After some time you are forced to restart VS Code, since it just becomes too slow. This also materializes as cached "ghost" versions of objects, where changes are no longer recognized by code analysis and compiler.
One more question: if you do a full build (ctrl + shift + B), does that cause the memory usage to decrease again? This should force a garbage collection.
Indeed, compiling the app will increase the RAM usage even more for a short time, but once it's done it goes down to ~1GB for the language server and ~2.5GB for VS Code in total.
However the "ghost" object problem is not solved by that. After pulling commits or applying stashes I regularly have to reload the windows for al to recognize the changes. Either the code analysis says references are not found, even though they are clearly there, or worse the compiler will use the old version of the file. This means you can't be sure what is actually compiled and published.
After a git pull a "reload window" is expected for now,
For developers who haven't yet 'discovered' this (i.e. had it revealed to them by a built app mysteriously failing at runtime, in ways the code can't possibly indicate...) - can your AL extension be updated to detect git changes and require a reload before building?
We should not be left having to remember esoteric knowledge that we accidentally obtained, in the Collective Memory of Developers, in 2022 - we did enough of that for C/AL ;-)
Of course, I understand that VSC might not give you any (nice) way to do this, but if so can this requirement at least be documented somewhere prominent?
Agree. We should document all scenarios when a reload window is manually needed. The collective memory on the other hand is a powerful tool :)
"Reload Window" does not work consistently. Does anyone know where the object cache is stored, so we can write a batch file to delete the cache files. This would save some time for some slower machines in our company, as you have to reload vscode 4 or 5 times in larger projects until everything works correctly.
In some cases, the only solution is to close all VS Code windows and to make sure the language server is no longer running.
@cstuber this is not enough with very large projects, unfortunately. I'm trying to create a batch file to wipe the cache plus do a "full restart", something like
Taskkill -f -im code.exe
rm {Folder i'm looking for}
code.exe
@matthias-planzer I agree with you. The phenomenon I'm often encountering is the compiler not noticing changes in files. I type code and at some point, it just stops processing the new characters and instead starts reporting syntax errors. "Reload Window" doesn't solve this, neither does restarting VS Code. Sometimes closing VS Code, waiting some time and starting it again helps. When this begins to happen I usually just restart the computer.