My development team has been through tough days detecting memory leaks during scene change. and we eventually found out that it was caused by PathPool (caching Path object in static members).
We just wanted not to burden GC and commented out [#define ASTAR_NO_POOLING] at the first line of PathPool.cs (but it seems that your comment at that line suggests NOT TO USE path pool.)
When PathPool is activated, and a path object is recycled into the pool, Path.OnEnterPool called. but in OnEnterPool, ‘callback’ delegate does not cleared, so objects related to the delegate reference cannot be swept away by GC. This caused duplication of atlas texture in asset bundles in my game app.
For now, we’ve solved this by just adding single line of clearing ‘callback’ reference in your OnEnterPool.
But it seems that Path.OnEnterPool/Path.Reset (called by PathPool system) needs to be improved by your side for preventing memory leak of user codes.
Do you have any plan about this? or still do you suggest not to use PathPool?
Please let us know.
Thanks.
Sehee
What I meant by that comment was that it was mainly for testing or if you wanted to measure the difference between using vs not using the path pool. I recommend using the path pool at all times.
Hm, yes that seems to be correct. The callback field is cleared when the path leaves the path pool (by the GetPath function) so it would likely be cleared at some point in the future, but you are right that it can cause temporary memory leaks. Maybe I will move the Reset call to the OnEnterPool call.
FYI, Calling Reset() in OnEnterPool(), (this was one of the options I’ve tested already) it could work without any serious problem. But when I look into the code inside Reset() funciton, you seem to design the function to be called right before Path object is to be used. There are many initializing codes inside Reset() function like ID assigning, obtaining list form ListPool, and marking start tick count for measuring calculation time, etc. So if you are going to solve this memory leak issue, you would better to divide the de-initializing codes from initializing code of Reset() to OnEnterPool() carefully.
Thanks again.
Sehee