Thanks Gaurav and Alex for the confirmation on the Strings. I did turn on the allocation stack trace option and the strings would show as being created in lines with basic expressions such as a toString() method or something like new XML(<string value>), so my hunch was that this was something internal and nothing I'd have to be too concerned with.
As for the label creation test, I realized that in the attempts I made earlier I made the mistake of monitoring the System.totalMemory value while running the app with the profiler (with the intent of looking for any correlation between the profiler's reported value and the System.totalMemory). Though I imagine most of the logging and performance measuring happens in the Builder process, I guess there is something inside the player that's also performing something cumulative that causes the player's memory usage to increase continuously. In any case, running a release build of the test application seems to keep the memory usage bound, just like Alex described. Thanks for your help in this, Oliver -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Friday, March 14, 2008 12:38 AM To: [email protected] Subject: RE: [flexcoders] memory leak questions 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 --------------------------------------------------------------------------- The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the TradeWeb e-mail system.
