X# slowdown in VS when editing PRG for a long time

[leon-ts]

Hi all,
I am using X# integration with VS 2019 (x86). When I edit relatively large PRG files (5000 lines or more), the code editor starts to slow down gradually. The longer I edit a PRG before closing it, the more the editor (on the tab with that PRG) starts to slow down. When I've finished editing a PRG, saved it, and close its tab, the editor may hang for a few minutes before the tab closes. For comparison, if the PRG was not edited at all or edited very little, then the tab closes immediately. That is, there is a direct correlation between the number of lines edited on a tab and the speed of the editor on that tab, including closing that tab.
This is observed in all recent versions of X# that I have worked with: 2.14, 2.16.

Does anyone else have the same problem?

[boonnam]

I have similar issue. It's the XSCompiler. It's consuming lot of memory. It's not just VS that becomes slow, it's my whole system. This usually happened after I do a build. I have to end it via Task Manager.

[leon-ts]

Hello Boonnam,
In my case, there is no XSCompiler.exe process in memory. For example, I launched VS and started editing a large PRG. I didn't run the compilation. After a long editing, only a separate tab starts to slow down for me, in which the edited PRG is open.
It seems that some data accumulates during editing and the more it gets, the slower the tab works, and then it takes just as long to close (the devenv.exe process completely loads one processor core for several minutes). Perhaps only Robert can clarify what it could be.

[robert]

Leonid,

It is very difficult to say what causes the problem.
If could be something in our code, or maybe we are doing something wrong which causes the VS editor to consume a lot of memory.

There is a lot happening (in the background) when you are editing:
- we are running the X# Lexer to determine the tokens in the buffer
- we are using the tokens to create information so VS can display elements in various colours
- we are running a parser on the list of tokens, so we can determine the list of entities and the blocks in the editor
- we are creating regions (the [-] and [+] tokens in the editor) for VS so it can collapse elements.
We are also feeding the controls that display the current type and member

Each edit in the buffer triggers this process again (with a delay, to keep things upto speed).
In theory there could be a problem in each of these stages.

We would have to run a .Net profiler on your VS to see if there is a memory leak somewhere.

Robert

[leon-ts]

Robert,
I'm planning to migrate to VS2022 (x64) one of these days. I'll see if this problem will be observed there.
In principle, the given problem should be easy to reproduce:
- open a large PRG file in the project (in my case it is 4000 lines)
- edit a few dozen lines (in my case, about 40 lines were enough)
- save changes
- close the tab

But I don't know if the context in which this is done matters. In my case, this is a solution that has 25 projects.

[Chris]

Leonid, Robert,

I did manage to reproduce this a couple times (with a "real" 8,000 line prg of mine), but out of 20-30 attempts it was only those 2-3, all the other times the file closed instantly. And still the delay wasn't huge, it was like 2-3 seconds here, but quite noticeable. Of course it might just be the Garbage Collector kicking in and releasing some (many) objects , so I'm not sure if it's the same thing that Leonid is seeing, but will do some more testing, to try to reproduce this more consistently.

Btw, my test system has an i5-8400 with 8 GB of RAM, which is mostly pretty used up already (85%) at the time I start the tests. Leonid, what are your system's specifications, just to get an idea? And how much memory do you see available at the moment the delay occurs?

[leon-ts]

Chris,

Leonid, what are your system's specifications, just to get an idea? And how much memory do you see available at the moment the delay occurs?

Device specifications:
Processor: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (4 cores, 8 threads)
Installed RAM: 64.0 GB
System type: 64-bit operating system, x64-based processor

Windows specifications:
Edition: Windows 10 Pro
Version: 22H2

My step by step with illustration:

1. Opened my solution named "WinTU" (25 projects) and opened PRG for editing (~4000 lines of code):

screenshot1.png (88.79 KiB) Viewed 1111 times

2. Edited about 40 lines of code and saved (didn't close the tab yet):

screenshot2.png (88.27 KiB) Viewed 1111 times

3. I close the tab (I clicked the cross on it):

screenshot3.png (99.38 KiB) Viewed 1111 times

Step 3 hangs VS for 1-2 minutes.

[robert]

Leonid,
Does your solution have a lot of external references?
We are caching some information for globals, functions and types from these references in the codemodel.
That may consume some memory, which could explain the slowdown.
We could probably solve that my moving some of the processing to external services (like the ServiceHub processes you see in your screenshot).
But that will make the processing a bit more complex.

Robert

[leon-ts]

Robert,
In the screenshot, the list of references in the main project of this solution:

screenshot4.png (16.77 KiB) Viewed 1111 times

This solution represents one of the three solutions (modules) of a large ERP system.

[leon-ts]

Robert,
I installed VS2022 (x64) and it has the same problem: the edited code tab in the big PRG closes for a few minutes. Does closing a tab really do something useful that is needed for further work in the current session? The matter is that the code is already saved on a disk and I just close the tab.