[gpz]

As I see, TrainCar doesn't implement IDisposable, so it is sure they stay in memory once loaded. There is an IsPartOfActiveTrain property of them, which controls unloading of bundled sound. AI trains members use it, but I'm not sure what happens with loose consists. I think TrainCars of loose consists will never be unloaded from memory.

[Csantucci]

Thank you for the analysis, Peter. This in fact coincides with my qualitative tests. Some time ago I made another memory usage test running a train back and forth, but without loose consists, and in that case memory remained constant when returning to the starting point.
In the case above and in similar cases I had the qualitative impression that memory usage growing from run to run was at least partially due to re-loading of consists.
So solving this problem would probably not only reduce occupancy of sound source buffers, but also reduce the general problem of unjustified increases of OR memory usage.

[James Ross]

gpz, on 18 November 2013 - 10:35 PM, said:

As I see, TrainCar doesn't implement IDisposable, so it is sure they stay in memory once loaded.

Where did you pick this up from? It is categorically untrue that classes need to implement IDisposable to be cleaned up/removed from memory.

[Csantucci]

I have rerun the activity depicted in the above screenshots, but this time without loose consists. I have again made twice the run from big station to intermediate station and back. These are the tree memory usage values at application start, at first return to start station, and at second return to start station: 1028 MB, 1123 MB, 1131 MB. The increase is justified, as James explained somewhere else. Important thing is that second and third value are practically the same, so no memory leak without loose consists.
The tests of my preceding posts however show that there is memory leak with the loose consists. So I'm not able to enter into Peter and James' discussion, but there is something about memory release of loose consists that does not work; this is evidenced both by the double memory increase I had in such previous tests and by the double entries in the active sound source list.

By the way loose consists are trains too, I guess of type static. Do they have to be explicitly disposed or James' rule applies?

[James Ross]

Csantucci, on 19 November 2013 - 02:14 AM, said:

By the way loose consists are trains too, I guess of type static. Do they have to be explicitly disposed or James' rule applies?

An object is collected (disposed) automatically once nothing else refers to it. So although we don't need to explicitly dispose them, we do need to make sure they are removed from whatever is holding on to them.

There are two main parts to a train: the simulation part, and the viewer part. The simulation part is not disposed unless it is an AI train and the AI is completed (and is removed), or that should be the case. If we disposed the simulation part, you'd no longer know where the train was! But this part should not use much memory at all. The viewer part is created on-demand, when a train is close enough to need to be visible, and should be disposed of once the train is far enough away to no longer be visible. There is also a cab part, which should work similarly to the viewer part.

It is quite possible we're not disconnecting the viewer or cab parts as we should; although I've carefully checked other parts of the viewer (mostly around terrain/scenery) to ensure we release things in due time, I have not done this with the train viewer parts. It's on my list though.

[gpz]

I would suggest Carlo to make a test by removing all the references to any sms files from eng files, to prove or exclude that this is because of the sound. If memory leak is gone, then it is a sound issue, if it is still there, then not.

(Just to make it clear: I am not a pro, just a "wannabe" programmer, so despite of Carlo's big words, what I say is not an analysis, just a thought of a (as we say here) sane peasant brain. So forgive me if I say untrue things sometimes, I believe the pros, no need for a decapitation.)

[Csantucci]

Hm Peter,
I have to modify about 80 trainset files... I will see. I don't think it can be - only - a sound problem. In my test with loose consists memory usage increased also from first to second return to the start station. And in both cases the sound source buffer was full. So it seems that some other thing increased.

James,
I'm sure you'll find something interesting in your checks about viewer parts of trains (and I suspect not only of static trains)!

[markus_GE]

Csantucci, on 18 November 2013 - 12:49 PM, said:

Referring to the request of ATW, it is not completely straightforward to generate and run such a release of OR, because it requires an extended development environment (Visual C# Express is not enough, or at least mine was not enough), and the change to the OS settings depends from the OS.

Isn´t there also a Utility out there that will perform this Switch on any existing program? I´ll dig in the swamps of my HD´Ds' Folder structures as I seem to recall I downloaded something like this for MSTS some time ago...

Cheers, Markus

[railguy]

I definitely think that loose consists may be one of the memory culprits. When I run activities with a lot of loose consists, I'm more prone to run into the problem with missing textures. However, it may not only be the "failure to unload" of loose consist files that causes the memory leak--it may be the way the program actually loads the file. I don't have a log on this, but here is why I think that might be the case. I run one activity that I built for Horseshoe Curve where I have about 3 AI trains, but very few loose consists. The player train is a 100 car coal train with rear helpers. The player train meets an AI train at Cresson--the AI train being an intermodal having about 70 cars. On the siding is one loose consist with one locomotive. About 2/3's of the time, the AI train will have missing textures if the loose consist locomotive is on the siding. I re-did the activity without it and re-ran the activity a couple of times--no missing textures. After reading this discussion, it got me wondering if the program somehow multiplies the file size of a loose consist for some unknown reason. My other completely off-the-wall speculation is that maybe the full-throttle locomotive loose consist issue might also be related to how the program treats loose consists. Maybe just a coincidence, but maybe not?

[gpz]

The full-throttle issue is a different thing, that is just a value somewhere set to 1 instead of 0.