Performance

[pzentner]

It seems, after a while working with VS Code and several compiles -> Run, the performance is degrading. Resources are available on the Azure VM (using the august image - not docker, since there is some other issue I can't figure out yet). However, once I start making changes (currently trying to add additional fields and groups to a custom page), I am seeing a lot of "red highlights" and errors popping up. It will take several minutes for the system to catch up to me typing and then finally removing the problem reports (those only were, because it was checking unfinished typing). Looking at the task manager, I have the Microsoft.Dynamics.Nav.EditorServices.Host running at 50+% CPU the entire time.

I am not sure what can be improved there, but the issue obviously is somewhere in the "live connection" to the NAV service tier instance and generated latency through this. I am going to keep monitoring this to see, if I can find a pattern when this starts happing. When I restart the service tier and VS Code, it starts working well again. Starting to narrow down the required actions to resolve the issue, but wanted to report it already.

[esbenk]

What is the project size approximately? What size of VM are you running on?

Very large projects will put more pressure on the system, but it shouldn't give the experience you are describing. I have worked with a 6000+ object project (W1) on my Surface Pro 4 with a good experience. With august update we made a number of performance improvements and changed the background compilation service. The language service will wait a second after the last keystroke before doing the first starting the background compilation for the edited document.

I'm very interested if you can narrow down the problem to specific tasks, since I haven't experienced that and I haven't heard anything like that from our internal teams.

[tfenster]

I can confirm that this is happening for me as well (local docker-based installation) with a very small project (approx 30 objects). I think it still happened with August update but am not 100% sure

[MikeGlue]

I'm also experiencing this on a Surface Pro 3 and the August update. I had to turn off codelens and then the issue seemed to go away......but I do love codelens so I'd like to keep it on. I have 87 object files currently.

[pzentner]

I have August update and probably 50 objects, so very small. The work around is to actually only close out VS Code and start it again. Service tiers, etc. do not need to be restarted. The VM is actually smaller than I thought, it's a D2 - I guess that's standard with the deploy package.

I noticed it happening mainly when working on pages or page extensions, I can get this to happen more often when adding or editing fields. I am trying to work on this a bit more to see, if there is more of a pattern.

[esbenk]

Have notice increased memory usage over time?

We will investigate this. If you have more information that can help us reproduce please let us know. E.g. working with certain objects etc.

[esbenk]

@pzentner @tfenster can you try to turn CodeLens of? Just add

"editor.codeLens": false

to the settings file? At let me know if it changes something.

[tfenster]

When it happens or to prevent it from happening?

[pzentner]

I have turned it off and will monitor it. And to answer your other question, I have seen increased memory usage over time, but not on the EditorServices or VSCode, but on the NAV Service Tier - and I would assume that this is from running the navx packages.

[MikeGlue]

I'll keep a better eye on memory usage as I've not been paying that much attention to it. It does look like it's increasing over time. I did look earlier today and the editor service was around 420MB. It's now at 485MB. It's been at least 2-3 hours since I first looked.

I've been creating a lot of new objects today as I'm building out a new functional area so not exactly sure if a specific scenario is causing it or not.

[esbenk]

@tfenster To prevent it. The CodeLens feature is costly. All other files most be scanned to find the show symbols and VsCode is requesting it fairly often. We may investigate if we should cache/limit the resources spend here.

[esbenk]

@MikeGlue More objects/code will create a larger working set, but it should only grow proportionally to the added code. Hard to say what is the right number here.

[tfenster]

@esbenk ok, will do. We are kind of finished with development of our first app and the current challenge is more about how to get it published (which is not very well documented, but here is probably the wrong place to discuss that), so not too much coding is currently happening. But there will be bugs to be fixed and improvements to be made and I'll try then and make sure my colleagues do the same

[MikeGlue]

This may or may not be useful, but here's what my last hour looked like. Most of this is what I would expect but looks a bit weird that while I was working in the same objects and reducing the overall compile errors, the memory usage was actually increasing. Over the course of the day I can see then how my memory usage got to over 400MB because I was working on a lot of different objects over the day, but I don't understand the memory increase as I am working within the same 2 objects for an hour.

In any case, if useful, here's what I saw while working away. What I was doing was bringing in 2 posting codeunits from my other app into the one I'm currently working on. Obviously that caused compile errors so I was just working my way through the references, etc. to point the functions to the current app.

The one thing I use a lot and have done so today, was using the rename symbol feature, as I'm doing a lot of this type of work today bringing over functionality from one app to another.

4:00pm - 170 MB (fresh launch, 87 objects) 4:07pm - 187 MB (modify 1 page and 1 table) 4:11pm - 198 MB (add 2 codeunits) 4:15pm - 226 MB (copy in functions from other codeunit and change variables, causing large number of compile errors [92] while references are being updated in code via rename symbol, etc.) 4:25pm - 206 MB (updates to new codeunits to reduce compile errors [80]) 4:37pm - 248 MB (updates to new codeunits to reduce compile errors [50]) 4:48pm - 249 MB (updates to new codeunits to reduce compile errors [31]) 4:55pm - 253 MB (updates to new codeunits to reduce compile errors [1]) 4:59pm - 236 MB (updates to a table to resolve last compile error) 5:01pm - 241 MB (F5 to compile and publish - no errors, successful deployment) 5:04pm - 170 MB (close and launch VS Code, 89 objects)

[pzentner]

I haven't done a lot the rest of the day (was mainly done for today and was working on testing and smaller things), but once codeLense was turned off, it seems like this issue went away. I have monitored it - whenever I did anything in VSCode and the performance overall was better and it didn't seem to get to the point where I would have to wait quite a while for everything to be sorted out. I will add more comments once I work more again.

[esbenk]

I will see if can limit the resource consumption used the CodeLens feature. Unfortunately all the fancy intellisense comes with a CPU cost.

[pzentner]

I think, some more advanced caching or limiting of when files are processed seems to be the best option between having the feature and having it perform well. the issue seems like it is a runaway task or something, because it shouldn't happen with such small projects or get worse over time.

So, only limiting resources might not fix the underlying issue, but I can't really point you to the pattern to repo the issue

[esbenk]

What I meant was, to be smarter about when we count references for the CodeLens. There may be other thing we can do.

Modern intellisense puts an almost constant load on the cpu - not just for AL. The C# solution I'm working on is also putting a significant load on the cpu in the background.

The important is to be smart about when and what to spend time on - and there may still be some bugs that also adds to the equation.

[DmitryKatson]

I can confirm that if I work with about 30 files in one Projects AL start to

• show compilations problems, that does not exist. If I click on problem it disappear
• slows down
• crashes AL sometimes (see https://github.com/Microsoft/AL/issues/540)
• shows such strange duplicate messages

I found that it happens when I modify pages and groups mostly

[StanislawStempin]

We forgot to update this thread. This issue should have been fixed quite a long time ago. Please let us know if you're still seeing the problem.