I saw different posts on forums in these days about issues related to poor Visual Studio Code performances when using AL language and opening big projects.
Microsoft’s recommendation for Visual Studio Code and AL are listed here and they recommend at least 16 GB of RAM, while 32 GB is the recommended way for large projects.
I think that not everyone of you have 32 GB on a local machine or on a notebook today, so how can we help our Visual Studio Code to perform better with a large AL project? I think that there’s not an official answer or a clear rule on this topic, but I want to report the tips that worked for me.
Despite on what many thinks, I’ve experienced that the main cause of large RAM usage from Visual Studio Code is due to the third-party extensions installed. If you have lots of extensions installed in your Visual Studio Code box (and this was my case because I don’t work only with AL) Visual Studio Code performances decreases. First advice if you have poor performances on your IDE is then install only the extensions that you need and remove the others.
You can check the installed extensions and how they perform also from the IDE with the following command:
This command will open a tab with a list of all your running extensions and with their Startup Activation time. If an extension has a log startup time, disabling it could help.
Doing that, you can work on tuning Visual Studio Code options. The second option where I have experience impact on performances is the al.BackgroundCodeAnalysis option (that permits you to specify whether the code analysis should be performed in the background or not). Setting
and using code analysis only from compilation helps on improving Visual Studio Code performances. It’s helpful also using only the required analyzers (if you have all the analyzers active, performances will decrease). Obviously, if you disable code analysis at all it helps a lot but I think this is not a practice to do.
Another option that could help (at least on some machines) is to switch the AL runtime to the .NET Framework runtime instead of .NET Core runtime using:
I’ve talked about this option here times ago. Despite the offial recommendations that say “Use the .NET Framework runtime for hosting the language service instead of the .NET Core runtime. Enabling this option might result in a reduced level of performance.” on some cases I’ve experienced exactly the opposite.
Other things that affects performances with AL:
- Workspaces: they’re useful, but if you have lots of projects on a workspace performances will go down
- Search: you can try to set files.exclude (global patterns for excluding files and folders from search index) or files.watcherExclude (global patterns of file paths to exclude from file watching) options
Things where I’ve not notice big improvements on performances (so not recommended for me):
- Disabling the Format on Save option
- Disabling code actions (al.enableCodeActions = false)
- Removing code lens (editor.codeLens = false).
I think that you’ve to try on your environment what fits your needs. Remember that these are absolutely not official tips and they can be different from an environment to another.