[Eldorado.Railroad]

In my test, refer to my post here above, going back and forth between world tiles reloads the SAME items over and over! This results in memory consumption that is NEVER released. You can replicate this "feature" yourself by observing carefully the F5 debug HUD with the all the performance graphs.

Steve

[Serana]

 Csantucci, on 11 December 2021 - 07:34 AM, said:

Cédric,
I've tested the Unstable release, but I am getting the problem I mentioned above, see picture
DarkSignals.jpg
The signals are dark.
This occurs with a high speed route, using a path where at the beginning there are traditional light signals, in the central part there are ERTMS signals, and in the end part there are again traditional light signals. When the train enters this last part, the signal lights don't appear, while this does not occur with the other official OR versions (testing and stable).

Is that Roma - Napoli ? In that case, I already have the map so I can do some tests with it.

 Csantucci, on 11 December 2021 - 07:34 AM, said:

I have also a question: you are mentioning data about memory occupation of the VRAM. Are you really mentioning VRAM, or is it DRAM (which is the one shown in the Debug Info HUD)?

When I talked about unmanaged memory ? I was talking about DRAM in that case.

 Eldorado.Railroad, on 11 December 2021 - 01:25 PM, said:

In my test, refer to my post here above, going back and forth between world tiles reloads the SAME items over and over! This results in memory consumption that is NEVER released. You can replicate this "feature" yourself by observing carefully the F5 debug HUD with the all the performance graphs.

Steve

Yes, I am seing a continuous increase in RAM occupation even without going back and forth.

What has been troubling me was that, when I used a memory profiling tool (dotMemory), after creating a snapshot, the memory occupation dropped suddenly.
Since there is a lot of garbage collections going on... perhaps we are throwing away too many variables and the GC is not quick enough to delete them all (that's what is called GC pressure).
That's probably why when the program is paused to create the snapshot, the memory occupation drops suddenly: because the GC had the time to delete the unused variables.

[Csantucci]

 Serana, on 11 December 2021 - 01:29 PM, said:

Is that Roma - Napoli ? In that case, I already have the map so I can do some tests with it. If you have downloaded only the base route, you should download also the patch http://www.trainsimh...ad.php?did=1979 that implements the ETCS signalling. You can run the route in autopilot mode with any trainset, disabling the TCS (so also a TGV...).

Yes, it is. I tested with a path from Napoli Centrale to Roma Termini using the HSL (in the route there are also two traditional lines (CASSINO and FORMIA) from Rome to Napoli)

 Serana, on 11 December 2021 - 01:29 PM, said:

When I talked about unmanaged memory ? I was talking about DRAM in that case.

I meant where you wrote "I went from 3 GB of VRAM usage to 1.9 GB".

[Serana]

 Csantucci, on 11 December 2021 - 01:40 PM, said:

You wrote "I went from 3 GB of VRAM usage to 1.9 GB".

That's GPU RAM in that case.


About the signal lights, if I understand this properly, once the train leaves the first area with conventional signals, the signal light texture is sweeped. It is not reloaded once we arrive in another area with conventional signals.
I have to take a look at where and when signal light textures are loaded.
Two solutions: either I mark them all the time in order for them to never be unloaded, either I find a way to reload them.

[Csantucci]

 Serana, on 11 December 2021 - 01:41 PM, said:

About the signal lights, if I understand this properly, once the train leaves the first area with conventional signals, the signal light texture is sweeped. It is not reloaded once we arrive in another area with conventional signals.

Yes, it's happening that.
I didn't find an easy way to solve that.

[Serana]

I think I fixed the signal lights.

[Csantucci]

Yes, it works now. Good job!

[Serana]

Seems like the dynamic track texture is not reloaded either.

[Eldorado.Railroad]

 Serana, on 11 December 2021 - 04:19 PM, said:

I think I fixed the signal lights.

In what build was this "fixed"?


Thanks,

Steve

[Eldorado.Railroad]

 Serana, on 11 December 2021 - 01:29 PM, said:

Yes, I am seing a continuous increase in RAM occupation even without going back and forth.

What has been troubling me was that, when I used a memory profiling tool (dotMemory), after creating a snapshot, the memory occupation dropped suddenly.
Since there is a lot of garbage collections going on... perhaps we are throwing away too many variables and the GC is not quick enough to delete them all (that's what is called GC pressure).
That's probably why when the program is paused to create the snapshot, the memory occupation drops suddenly: because the GC had the time to delete the unused variables.

Cédric,
You have made a very astute observation here. I have noticed much the same, that is, when the user minimizes the OR runtime window, often memory gets released. This is most likely what is happening when (dot Memory) is used in the manner you have described.

I took some time to do a bit of reading about GC pressure. The following realizations have come to mind, a bit late but of course:

1) I assume that heap memory is being used here more often than not, as it is only at runtime that the size of objects are determined. Namely when shapes and textures are loaded for a given tile. There is really no other way of doing it.

2) I have observed in OR, and wondered why GC seems to be "hyperactive". If the camera is on a given tile and NOT moving about, nor are new shapes appearing, such as a consist with new shapes/textures, why is GC pounding away in the background?

3) With 2) in mind, it "appears" that the loader thread whether apparent or not has priority over GC, instead of the other way around. This means that GC will never catch up as whatever is discarded from the heap, is replaced immediately with the loader thread. This might explain why moving the camera between tiles always consumes more memory, because GC never got there first.

4) As I recall in the older XNA versions, when the camera moved from one tile to the next, and at times several tiles, consists (shape/textures) were visually dumped from memory, as indicated in the F5 debug hub, but also graphically seen in the task manager memory profiler for runactivity.exe. This has the side effect of a split second hiccup in frame rates as a bunch of memory was cleaned up. This never happens in the Monogame version. No hiccups, but no memory recovered either.

5) I speculate that this is a synchronization problem. Meaning, you can load or GC, but you cannot do them at the same time, as they are in conflict with each other. The trade off here is, yes, there may be hiccups in frame rates, as the loading thread attempts to populate the runactivity.exe memory space in the heap when a new tile is entered, as you may have to have GC finish first before loading. The same will be true for GC. You cannot do GC, with the loading thread running, it must wait.

6) It is inevitable, that there is going to be some memory fragmentation in the heap given that it is only at runtime that runactivity.exe "discovers" what to load next and how much memory is needed for a given tile. This means that unless we are very lucky, some memory leakage is going to occur. But it really should be far less than what it is now, and certainly not long lasting. I hope!

7) In my wildest dreams, I have thought that maybe runactivity.exe, would parse all the world tiles first, and "decide" what shapes/textures should never be discarded from memory, if it is used in more than one tile. But in practice, I doubt that would really be worth the effort!

Steve