If you want to test using System.totalMemory, generally, I set up a timer and run a loop forever (create the label on the first timer call back, remove it on the next call back, etc) and watch System.totalMemory. It will grow for a while and should stop growing or slow down to a crawl. It may not stop because of the number-to-string you do to report the value.
Strings without back-references are generally ignorable. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gaurav. Jain Sent: Thursday, March 13, 2008 8:46 PM To: [email protected] Subject: RE: [flexcoders] memory leak questions I believe some strings are interned by the player, there was a fix related to this in flex 3, and now the number of such strings is a lot less than with flex 2.0.1. If you run profiling session with the option to generated objects stack traces, you can find out where the object was created using the allocation trace. The profiler memory usage is specific to the application being profiled. Profiler memory usage may not always map to System.totalMemory as System.totalMemory also shows memory for the VM and the rendering engine. As you create a new Label in each iteration player may allocate more memory than required (player allocates memory in chucks), probably that is the reason why you don't see the increase in profiler numbers. But if the increase was significant it would be reflected by the profiler. Also there is no way you can force memory release in the release player. Thanks, Gaurav
