[Csantucci]

This is true for both OR NewYear MG and OR Ultimate.
Running activities on the Bernina route, I noticed on the debug info window that after about 1 hour of run I get 1 GB of used memory (they were 330 MB at game start), while if I run OR NewYear MG at 32 bit, I get a bit less than 500 MB. I don't know if it's normal, and I don't know what to do to improve it, but as a suggestion I'd say that people having only 4 GB RAM (like myself) may more conveniently run OR NewYear MG using the 32 bit option, which behaves more or less like the non-MG versions in terms of memory used. They still will have access to the full 4 GB of RAM.

[wacampbell]

In a 64 bit program every memory pointer is double the size. Many CPU instructions are double length as well. That could account for some increase in memory use. If your program doesn't need to access large memory, 32 bit is usually faster and more memory efficient.

[R H Steele]

I don't know if this is related, but after running long activities -- reasonably well stocked with loose consists -- over a couple of days....the activity takes increasingly longer to save...frequently OR just stops working while trying to save...the FPS drops and eventually it becomes impossible to run or save the activity. OR monogame...recent versions up to Rev55.Running Win7 64bit, 32G memory

[Bert Wise]

Further to what Mr. Steele mentioned, I have also found that long activities, with plenty of AI trains and loose consists do start to slow down and hesitate, with reduced fps as well.

The attached image is from the end of my 5 hour activity completed in a single session. Task manager shows Open Rails using 23 of my 24 GB ram, hence the sluggishness of OR at this point. What I also find interesting is the OR F5 debug hud shows 2 GB of memory usage. While running this activity I watched at this counter increased up to just under 4.1 GB, then reverts back to around 1 MB and continues to increase up to just under 4.1 GB, then resets again. Rinse and repeat several times over the course of the activity.

 Kamloops.jpg (361.9K)
Number of downloads: 15

I have found that if I save the game after an hour or so, exit OR, fire up OR and resume from the save, memory usage according to Task Manager is low again. So as long as I save, exit, then resume several times over the course of the activity I can avoid the sluggishness.

Please, I am not complaining or criticizing, just making an observation about how Monogame handles memory and the discrepancy between Task manager and the F5 hud. I am ecstatic about being able to use more than 4 GB of ram and being able to fill up yards and have lots of diverse AI traffic.

Bert

[Csantucci]

Thank you for your contributions.
@ Gerry: I think that what you point out could be caused by the fact that saves not only save the actual situation of trains etc., but also the list of all player commands, and this list clearly grows by time. This list is saved in order to be available for a replay command. Maybe a fast save command could be created, that saves without the list of executed commands, and that therefore could be faster.

@ Bert:
what you say about the fact that the memory consumption restarts from 0 everytime it hit the 4 GB value seems a clear bug, and I will check if it can be removed. Unfortunately I wouldn't be able to test it.
It is also true that restoring a saved activity leads you to a memory usage that can be significantly lower than the one before saving; so there seems to be a real and consistent memory leak problem. However I wouldn't say that MG is the culprit, because running OR at 32 bit I don't get the problem and see an increase comparable with the one of the non-MG version. So for sure running at 64bit makes the problem particularly visible. Investigating where the problem lies seems particularly difficult.

[Csantucci]

In revision 58 of OR NewYear MG there are two changes that address some of the issues:
1) the RAM used is now correctly displayed in the debug info HUD, also when its value is above 4 GB
2) a general option has been added that, if unselected, does not store the player commands during the game. This means that game save is faster for long acctivities; with such save only a restore is possible, and not a replay; so if one does not use the replay feature, it is convenient to uncheck such general option.

[Bert Wise]

Hi Carlo

I can confirm that the F5 hud no longer stops at 4.1GB. It continues to increment as the activity progresses.

Thank you for that.

Bert

[Csantucci]

In release 59 I have added a General Option "Reduce memory usage" that reduces memory usage. It could be useful when running long and complex activities. In my tests memory used was reduced by about 30%.

[trainmanaustin]

Digging this up again. I was running the Double Empty Grainer activity on TS Mullan Pass in 64bit mode. I had my HWInfo64 open and was watching my system vitals. About half way through the activity, I got an error message stating System.OutOfMemoryException: Exception of type "System.OutOfMemoryException" was thrown. Only 41.6% of my physical memory (8GB installed) was utilized but my virtual memory was at 99.9% (just over 8GB). I have pagefile disabled on my system as I have a SSD as my boot drive and all of my MSTS/ORTS installed on it as well. I am running Rev.68 of MG on WIN 10 64Bit. I guess I do not understand how I can have over half of my physical memory available but my system is still using all of my virtual memory with pagefile disabled..