1 person found this helpful
If the profiler says memory is growing, take snapshots at various times,
remove filters, remove %, sort by class and manually compare the instance
counts to make sure everything is the same. If instances of anything are
growing, figure out why as you have to make sure your instance counts are
the same before you start looking elsewhere.
The profiler ( so does the Window’s task manager) shows that memory is allocated ( and growing) when the ROLL_OVER / OUT event handlers are invoked and do their thing.
Also it shows memory reduction by GBC when that happens.
Thus, because GBC does reduce the memory allocation ( either if I wait long enough, or manually via the profiler) I’m assuming that the operation free-up the memory blocks it consumed by the invocation, and it means that there is no “memory leak”.
The problems ( as I stated originally) are:
1.) Why, GBC is not occurring efficiently to take care of business, and/or how to persuade it to do so.
2.) The amount of memory allocated each invocation appears to me much more than I expected, just for addChild / removeChild of a reusable display box that is only created once.
I’ll take your advice and do a more thorough profiling to get to the bottom of this.
Hoping for a shortcut is allowed (only occasionally...)
There is a hack using LocalConnection to try to force GC. GC is only
otherwise called during allocations as pages of memory fill up. If you are
running a cycle (create stuff, free stuff, create stuff of the same size)
memory really should not grow unless you are creating "lots of stuff". GC
will not clean everything if it runs out of time. If you force GC, you may
I don't really think there is a shortcut here. Compare some snapshots. If
something isn't being freed (like a bitmap) you will see growth.