Memory Leak Hand-Off
Hey Folks! As Friday evening rolls around, I've taken my memory leak as far as I could. Tiago tends to put some hours in on weekends, so I've checked in my code for him to look over, and see if it's worth continuing.
The big difference I can see in my code is that it stops runaway memory use from encounter items. Each encounter was leaving its items in memory until the app closed, and that adds up. Assuming this was happening during battles, it might explain the leak Tiago was seeing in combat. At the very least, it was happening in cryo and other encounters, even if the user just reloaded the current move over and over. (E.g. trying different choices to see response text change)
So in theory, this might solve the long-term memory leak.
In the shorter term, I didn't see much of a memory drop. In fact, it might be slightly higher. But that might be in exchange for faster data loading, as the game was previously loading and unloading the same items over and over during certain actions (e.g. cycling through a weapon's attack modes, campsites, recipe hints, newspapers). Now, the game leaves these special types loaded for faster reading. So some increase in overall memory, but less reading/processing from storage (which, come to think of it, might save memory that would've been consumed by the data parser).
It still has issues, though. AI are leaking items when the game quits. And we have a lot of catching-up to do testing this new Item code to make sure it's as stable as the old code. Hopefully, Tiago's fresh perspective on my code will highlight anything I've missed. And ultimately, help us decide whether to push forward or revert to the old code and try another solution.
The good news is that his break from memory leaks has given him time to work on the rest of the bugs he's had on hold, instead of spinning wheels on this memory leak.
Probably not the most exciting week for all you readers out there. But a necessary one. Have a good weekend, all!