Quote
I am starting to think that exchanging information through strings is a bit expensive in resources, and it gets worse and worse when the route gets bigger.
I have a case where the route is so huge (so it has a huge number of signals) and, on some computers, even with optimizations to create less strings, the garbage collector can sometimes not be quick enough and we get slow memory leaks.
Yes, string manipulation has to be done with care for this scripts. There are a lot of signals being cyclically updated. For my scripts, I tried to minimize heap allocations taking two different approaches:
- For normal signals: I use pre-allocated strings to extend the 8 MSTS aspects to the 16 aspects needed by Spanish signalling. This approach doesn't use heap allocation.
- For ETCS balises: the text aspect corresponds to the binary-encoded telegram, which is dynamically constructed. In this case, there's a lot of string manipulations, which I try to reduce by using string builders where possible. Also, telegrams are updated only when there is a relevant change in signalling (this feature is also used to fill the M_MCOUNT balise message counter). Because of this, the performance impact should be negligible.
I don't see any problem in principle for giving access to signal scripts in other signals, as that would be faster than communicating with strings. Depending on the info that you want to transmit, you can also use the shared Dictionary<int,int> containing each signal's local variables.
For communication with TCSs there's a problem: in Multiplayer mode the signalling information is only fully available at the server, so anything that is made available to the TCS has to be serialized and sent through the internet.
I see that you encode data to be used for different TCSs into the same string, using lists to encode and decode. This is very expensive if it has to be executed several times in the same update cycle. Would it serve your purposes if the localStorage Dictionary is made available to the TCS scripts?