Well, in this case the answer is fairly straightforward:
We normally have a class called ForegroundUnitType, which stores all of the data that is per-ship-type per-player. Some of that stuff varies by player from things like handicap or if they are AI or human (like description text for that, mainly), and some of it varies by ship cap scale. It also included an even larger number of things that
never change per-ship-type, including huge arrays of stuff about which ships can hit which other ships, etc, but these were getting duplicated 10x, since there are 10 player slots.
The problem is, this class was absolutely huge, and included a huge amount of text, too. What had started out as a really efficient way to do things, over time, became partially inefficient because of the introduction of those variances like ship cap scales, etc. That really messed with things more than I realized, when it came to RAM use.
My solution was to split ForegroundUnitType into two parts: ForegroundUnitType and ForegroundUnitTypeImmutable. The second class includes stuff that is per-ship and which will NEVER change throughout the life of the program. Not based on player, not based on ship cap scale, nothing. This was... by far the bulk of the data in ForegroundUnitType. All the rest of that stuff that DID vary, I left in ForegroundUnitType. Then ForegroundUnitTypeImmutable is only ever instantiated once per ship class, right at program start, and then every ForegroundUnitType of the corresponding type references the immutable class as a sub-object that lets all the semantic relationships remain largely the same.
The reason that this wasn't an obvious optimization, now or in the past, was that the individual objects are so small that they don't show up in the profiler from Unity. Partly that's because their profiler is... ahem... not that great, and partly because their deep profiler crashes when profiling a game as large as AI War. Because it's trying to cache all its results data in memory. Since this memory explosion was post-unity switch, and so diffuse, we didn't find it.
What started getting me thinking about this, however, was the fact that AVWW has SO much going on onscreen and such, but is only using between 20-50 MB of heap at any given time. Right after program start, lately AI War has been using about 250MB of heap, without even loading a savegame, just from instantiating all of the metadata about ships, loading in the localization files, etc. That seemed... way too high, and ForegroundUnitType was the most obvious potential culprit. But I was still really taking a leap to even spend a few hours working on that, because it could have led to not much gain and just a few hours wasted and code reverted back.
Frankly I'd hoped to save about 50MB, but on program load it's actually about 190MB from what I'd been seeing directly prior to starting this optimization. It's only using 60MB of heap when loading the program now.
Out of a pool of 900MB, that's pretty huge. After loading Shadoz's savegame and then stopping the unity editor, then restarting the game, I'd get a heap error every time (the unity editor keeps heap somewhat in use between runs, unlike the fully compiled game). Afterward, it doesn't even blink.
Win.
