Memory allocation / freeing / leaks / expanding universe

AtomicDryad · Post by **AtomicDryad** » Wed, 14. Apr 10, 05:01

Recently my savegame has been growing (32 megs to 52 in 2 days, it was 13 megs 1 month ago...) and I've been experiencing more slowdown.
I've been trying to find out WTF is doing this, and I only have a few possible suspects:
New version of PM (things -really- started to slowdown after I started testing this) http://forum.egosoft.com/viewtopic.php?t=255379
STO (constant 2 ms while loop)
And last but hopefully least, my chat script. (800-1200ms while loop that re-reads a T file that -constantly- changes). http://forum.egosoft.com/viewtopic.php?t=275233

My chat script uses a frontend and a 'daemon' that runs on a station in null. When starting, the frontend creates a menu array, then starts the daemon, passing it the array as an argument. The daemon, in a while loop, reads the T file, parses it, and adjusts the array in the following fashion:
Truncates it via 'resize array'
append to array (stuff)

If the frontend isn't running, and a 'run in background' local variable is not set, the daemon does 'return null'. If the bg variable is set, the daemon sets an local variable = $menuarray, and continues functioning. A new frontend would thus read the local variable, set it null, and continue to function as the original.

I would assume resize array de-allocates the memory and thus any information that would be written to a savegame. I also hope that setting a global/local variable that's an array ptr = null (or a temporary script variable for that matter) would de-allocate memory.

I'm hoping that someone who definitively knows how the script engine works (perhaps an Egosoft dev) could confirm this. If it indeed does not then this is a big problem that's literally growing as I type.

If there are memalloc issues in regards to re-reading a T file that's constantly in flux, or the other methods I have described above, please let me know. The behavior of arrays=always pointers (even persistent variables) might lead to 'droppings' scattered about if a scripter isn't careful.

Also, does -removing- a script from the script dir terminate running instances on reload? And if so, does that clear any memory? Is there any way to dissect and inspect a savegame or the entire universe for that matter?

edit: Aha! For those who wonder, zcat X01.sav | strings |less is somewhat enlightening.

AtomicDryad · Post by **AtomicDryad** » Wed, 14. Apr 10, 05:28

/d/games/x3tc/_user/save# zcat X01.sav|strings -n 8|grep plugin.FDN4.Station.Task |wc
2538870 11642631 193370483

192 megabytes, out of 235 megabytes (uncompressed|strings -n 8), is DEBUGSPEW(tm) from 'FDN' (another script). I just went on a station killing spree and my savegame is down to 18 megs again!

....now the question is, why didn't 'clear debug messages' work? I checked most of the stations for debug messages before killing them, maybe I missed one? Or is this a bug? o.o

*goes over things more slowly. Prevents Ore Mine L Alpha from destroying the universe.*

Would someone care to explain the structure of a savegame and tell me where to look for the object that lines of DEBUGSPEW(tm) resides on?

Post by **Graphil** » Wed, 14. Apr 10, 11:24

This seems to be more scripts and mod related rather than the standard game so moving.

AtomicDryad · Post by **AtomicDryad** » Wed, 14. Apr 10, 11:51

Since this is in a public forum now I'll add that the issue was caused by not turning off the debugger, not the FDN script >.>

Logain Abler · Post by **Logain Abler** » Wed, 14. Apr 10, 11:55

I can stop sweating now!

LA

Post by **Cycrow** » Wed, 14. Apr 10, 13:26

Save games are essenislly a memory dumps of the running story engine. So every thing in memory at the time is written to the save game

As for arrays there is a garbage collector I believe that will clear the arrays when no longer used

rujikin · Post by **rujikin** » Fri, 21. May 10, 20:12

Concern priority

Save game size <<< Loading time between sectors <<< Lag During Sector Flight <<< Lag during fights

I have 138 GB/320GB hard drive free. A large save game is the least of my concerns.

Post by **Cycrow** » Fri, 21. May 10, 20:27

actually a large save game can indicate that theres a problem.
which can result in slower loading times, and increase lag in the game.

dpadula · Post by **dpadula** » Sun, 23. May 10, 14:23

So then is there a script or command that can be run to clean up the save game size without messing up the game? If there is maybe that will fix the issue.