3 Replies Latest reply on Jul 11, 2012 9:36 PM by kglad

    Problem with exe compiled in CS5.5, good in CS5.0


      I have a flash application with ActionScript 3.0. I use to compile the code with CS5.0, and it was all perfect. But, now I upgraded to CS5.5, and it started giving problems. When I compile the fla file to exe, and run it, it runs perfect for some time, then it starts getting heavy, using lots of CPU cycles, and eventually the computer hangs. If I again compile the same code in CS5.0, it runs perfect again. Can anybody help me to solve this issue.

        • 1. Re: Problem with exe compiled in CS5.5, good in CS5.0
          kglad Adobe Community Professional & MVP

          Memory Tracking

          The code below is adapted from Damian Connolly's code at divillysausages.com.  The MT class reports frame rate, memory consumption and what objects are still in memory.  Using it is easy.   Initialize it from the document class




          where this references your document class (i.e., the main timeline) and reportFrequency is an integer.  The main timeline reference is used to compute the realized frame rate and reportFrequency is the frequency in seconds that you want trace output reporting the frame rate and amount of memory consumed by your flash game.  If you don't want any frame rate/memory reporting pass 0 (or anything less).  You can still use the memory tracker part of this class.

          To track objects you create in your game, use:




          where the first parameter is the object you want to track (to see if it is ever removed from memory) and the second parameter is anything you want (typically a string that supplies details about what, where and/or when you started tracking that object).

          When you want a report of whether your tracked objects still exist in memory, use:




          I'll show sample code using MT after discussing details of the MT class in the MT class comments. It is not necessary that you understand the class to use it but it is a good idea to check how the Dictionary class is used to store weak references to all the objects passed to MT.track(). 

          Similar to the observer effect in physics, the mere fact that we are measuring the frame rate and/or memory and/or tracking memory, changes the frame rate and memory of the game.  However, the effect of measurement should be minimal if the trace output is relatively infrequent.  In addition, the absolute numbers are usually not important.  It is the change in frame rate and/or memory use over time that is important and for that, this class works well.

          This class does not allow more than once per second trace output to help minimize spuriously low frame rate reports caused by frequent use of trace.  And, you can eliminate trace output as a confounder of frame rate determination by using a textfield instead of trace output.



          package com.kglad{

                import flash.display.MovieClip;

                import flash.events.Event;

                import flash.utils.getTimer;

                import flash.system.System;

                import flash.utils.Dictionary;

                //  adapted from @author Damian Connolly

                //  http://divillysausages.com/blog/tracking_memory_leaks_in_as3

                public class MT {

                      // Used to calculate the real frame rate

                      private static var startTime:int=getTimer();

                      // Used to generate trace output intermittantly

                      private static var traceN:int=0;

                      // Megabyte constant to convert from bytes to megabytes.

                      private static const MB:int=1024*1024;

                      private static var mc:MovieClip;

                      // d is used to store weak references to objects that you want to track.           

                      // It is the essential object used to memory track in this class.                  

                      // The true parameter used in the constructor designates that                         

                      // all references are weak. That is, the dictionary reference itself                

                      // won't prohibit the object from being gc'd.

                      private static var d:Dictionary = new Dictionary(true);

                      // Used to trigger a report on the tracked objects

                      private static var reportBool:Boolean;

                      // Used to (help) ensure gc takes place

                      private static var gcN:int;

                      // This is the variable that will store the reportFrequency value that              // you pass.

                      private static var freq:int;

                      // A constructor is not needed

                      public function MT() {


                      // traceF() is the listener function for an Enter.ENTER_FRAME event.  If                 

                      // the game is running at its maximum frame rate (=stage.frameRate),              

                      // traceF() will be called stage.frameRate times per second.

                      private static function traceF(e:Event):void {


                            // This conditional ensures trace output occurs no more frequently                      

                            // than every freq seconds.  If the game is running at                            

                            // stage.frameRate, output will occur at approximately freq                             

                            // seconds.

                            if (traceN%(freq*mc.stage.frameRate)==0) {

                                  // This is used to (try and) force gc.

                                  gcN = 0;


                                  trace("FPS:",int(traceN*1000/(getTimer()-startTime)),"||","Memory Use:",int(100*System.totalMemory/MB)/100," MB");





                      // Called just prior to the above trace() and called just prior to a

                      // memory report.  When called just prior to a memory report, reportBool      

                      // is assigned true.

                      private static function forceGC():void {

                            // The first call to System.gc() marks items that are available                    

                            // for gc.  The second should sweep them and the third is for good   

                            // luck because you can't count on anything being predictably

                            // gc'd when you think it should be.


                            gcN = 0;


                      private static function gcF(e:Event):void {

                            // System.gc() initiates the gc process during testing only.  It

                            // does not work outside the test environment.  So, if you are using this class to test a game that is installed on a mobile device, System.gc() will not clear memory of objects ready to be g



                            // 3 System.gc() statements is usually enough to clear memory of

                            // objects that can be cleared from memory.

                            if (gcN>2) {


                                  // Here's where reportBool being true triggers the memory    

                                  // report.


                                        reportBool = false;





                      // Memory report.  All objects passed to d in the track() function,

                      // if they still exist, will be displayed by the trace statement along

                      // with the additional information you passed to track()

                      private static function reportF():void{

                            trace("** MEMORY REPORT AT:",int(getTimer()/1000));

                            for(var obj:* in d){




                      public static function init(_mc:MovieClip,_freq:int=0):void{







                      // This the function you use to pass objects you want tracked.

                      public static function track(obj:*,detail:*=null):void{

                            d[obj] = detail;


                      // This is the function that triggers a memory report.

                      public static function report():void{

                            reportBool = true;





          • 2. Re: Problem with exe compiled in CS5.5, good in CS5.0
            rahulkumbhar Level 1

            Hi kglad, thank for the reply.


            I understand you are trying to see if there is any memory leaks in my code. Let me explain you the scenario. I have a this flash application running on one computer. There is another computer which sends some data over TCP/IP, i.e. I am using sockets in my flash application to read those values and accordingly change the looks of some icons, or display a message on my flash. I create all the objects at the start. And I have to keep this application running for the whole day. Whereever, I run the other application which sends data to my flash, they get connected and work accordingly. I am just concerned, why is it, that the exe compiled in CS5.0 works like charm, but gets slower as the time passes with the exe compiled in CS5.5. Are there any publish settings I need to change. Or is there any library that CS5.5 uses different than CS5.0 which is causing this slowdown. I would still try to use your program to check any memory leak. But as to what I understand memory leaks could be caused by creating new objects and not freeing the memory after the use of those objects is finished. But here, I just create the objects at the start, and keep running the application the day long. Not sure where the problem is.


            Thank you

            • 3. Re: Problem with exe compiled in CS5.5, good in CS5.0
              kglad Adobe Community Professional & MVP

              there are differences in how swfs publishes by different versions of flash pro handle gc and there are differences in gc handling (and performance) by different versions of flash player.


              there are no differences in publish settings.