AI War Beta 5.047-5.049 Archived Memory

[keith.lamothe]

(Crossposted from this blog post)

This one is mostly a quick release to get a fix to some recent memory/performance problems out along with an advanced setting slider to help players directly experiencing those problems see if the sprite-pooling (or lack thereof) really is the cause.

Also a significant rework to the Spire Archive, which won the most recent "Worst Unit" poll.  We'll be dealing with the other winners from that poll and the two nerf polls soon too, but we wanted to get that sprite pooling thing out sooner than later so we can get feedback and see what else needs to be done on that side of things.  There's a couple miscellaneous changes in there too, and if you like Zenith Electric Bombers you'll like that they're now immune to instakill (Ion Cannons = Now Sad).

Update: 5.048 just removes an optimization in 5.047 that was causing something very like a memory leak.  Sorry about the goof there.

Update: 5.049 fixes a problem with the new Spire Archive seeding logic where it was trying to put them on invalid planets (rather, planets that would be valid later but weren't at that point in the process).  This would cause starting a game to fail when it happened, so wanted to get the fix out now.

Enjoy!

This is a standard update that you can download through the  in-game updater itself, if you already have 4.000 or later. When you  launch the game, you'll see the notice of the update having been found  if you're connected to the Internet at the time.  If you don't have 4.000 or later, you can download that here.

[platinawolf]

Woo, one might actually want to take the library now

[Cinth]

Added new slider to the Advanced tab of the Settings window: Sprite Pool Size
        This option was mainly added to help players find some memory-crash and performance-regression problems and in general you shouldn't change it unless you know what that means.
        Low pool sizes will keep possible memory footprint lower and help keep the pool from causing excessive memory use, but will also substantially reduce performance when there are not enough objects in the pool to handle all the things being drawn in a given frame.
        High pool sizes have the opposite advantage/disadvantage.
        The default of 5000 should handle most sane cases but shift-clicking around with a bunch of selected ships can pile up a bunch of lines (and thus sprites) in a hurry.
       

    Made the sprite pool periodically release the memory its holding (at the same times the game trims other parts of heap usage).

This looks pretty cool
Just going to ask what it means, and the expected behavior. Once I have a good idea, I'll give it a "stress test".
Otherwise, for now, I'll leave it alone 

[keith.lamothe]

Added new slider to the Advanced tab of the Settings window: Sprite Pool Size
        This option was mainly added to help players find some memory-crash and performance-regression problems and in general you shouldn't change it unless you know what that means.
        Low pool sizes will keep possible memory footprint lower and help keep the pool from causing excessive memory use, but will also substantially reduce performance when there are not enough objects in the pool to handle all the things being drawn in a given frame.
        High pool sizes have the opposite advantage/disadvantage.
        The default of 5000 should handle most sane cases but shift-clicking around with a bunch of selected ships can pile up a bunch of lines (and thus sprites) in a hurry.
       

    Made the sprite pool periodically release the memory its holding (at the same times the game trims other parts of heap usage).

This looks pretty cool
Just going to ask what it means, and the expected behavior. Once I have a good idea, I'll give it a "stress test".
Otherwise, for now, I'll leave it alone 

Hopefully the slider can go away once we figure out what's going on better, this is just to help us figure out what's going on

The expected behavior is that the game will:
A) Not crash from out-of-memory in situations that it didn't crash like that in 5.041 or earlier. (5.042 is when we backported a lot of render pipeline and other stuff from AVWW)
B) Not bog-down performance-wise in situations that it didn't bog down like that in 5.041 or earlier.

Sprite pooling is only one part of what was backported, but we've already undone so much of the other stuff that we think this is the main possible culprit left   So finding a value on that slider that doesn't break either of those expected condition seems plausible and would be a great step in the right direction.

[TechSY730]

Sprite pooling is only one part of what was backported, but we've already undone so much of the other stuff that we think this is the main possible culprit left   So finding a value on that slider that doesn't break either of those expected condition seems plausible and would be a great step in the right direction.

Another step in the right direction is to somehow convince the Unity guys to start bundling their product with a newer version of Mono that doesn't have such a "derpish" GC implementation. That way, poorly sized pools would cause bad performance, not crashes.

But yea, short of that, this sort of thing will be helpful.

[Cinth]

On a sad note.. I've already had a CTD .. didn't do anything with the added settings.. I'll bundle everything up in a moment.

[amethyst]

Same here, had a crash with the new version while all previous versions for the past few months worked fine. Mantis report is #9044.

[platinawolf]

There is a memory leak! Eech! Gonna uppload a save-file once I've made sure it triggers the leak good and propper ^^*

[Cinth]

 

Here is what I have. 

[platinawolf]

Move the view between Qwbark, Quonkintin and Diqapu to see the biggest jump in memory use,,, Keep jumping between and eventually it will crash...

[keith.lamothe]

Thanks for the saves   I think I know what may be causing the additional instability.  Basically whenever you switch planets it's supposed to empty the pool and start over so the old objects can be garbage-collected.  Well, I think it's hanging onto references to those objects somewhere, causing memory to just keep going up instead of going down there.

[keith.lamothe]

Hmm, switching back and forth between the high-ship-count planets in platinawolf's save did keep bumping memory up (it wasn't garbage collecting between planet switches at that point, afaik) but when the external "private bytes" listed in process explorer it got around 1,275MB it didn't get any  higher no matter how much switching back and forth I did.  It eventually climbed above 1,300MB for other reasons.  The managed heap wasn't getting bigger than 200MB and would always go back down to 100-120MB after each GC so while it's probably hanging onto a larger chunk than that for the heap from the external perspective the heap is definitely not killing things.  Gotta be the unmanaged memory.

*scratches head* <-- confused programmer

Well, will try turning off the "clear the pool" logic and see if that helps, since it seems to be making the game unstable for people for whom it was stable in the previous version.

[Cinth]

In the process of seeing if I can reproduce but I did manage to force a crash.

Seed 360448308 X map 120 planets. take all 16 HWs. (10/10 AIs) set up a defence for the first few waves (about 10 minutes) and beach head the cross road planet in the middle. I researched all T 2 turrets and built all of the there, and I kept building stuff like tachs and FFs. rally the production buildings to the planet. at about 40 minutes I hit 1.8 GB mem and CTD.

Edit: Keep on buildin and it keeps on piling up. SS w/ F3 menu open and Task manager.

Edit2: Here is the save that I built up on. Hop into murdoch and just keep expanding the beach head. build all the turrets and then pile on Forts... crank the speed up to +10 to expedite the process.

[keith.lamothe]

Update: 5.048 just removes an optimization in 5.047 that was causing something very like a memory leak.  Sorry about the goof there.

[Cinth]

Night and day difference here. SS of the same info as the last. Used the started from the same save I posted above.