3 Replies Latest reply on May 9, 2013 9:37 AM by Flex harUI

    Flash builder profiling: methodClosure

    Nielzz Level 1

      My app currently used 40% CPU when Idle and without anything happening. (Even with framerate set to 2fps)


      I've been reading all the stuff on profiling and I understand that objects which are not garbage-collected cause memory problems.

      But this is the start of the application, not much data has been sent/ received, and there should not be that much objects.


      Also, the CPU should not have anything to do with objects that are in momory, right? Is there anyway of seeing what the CPU is doing?


      I did find a lot of 'MethodClosure' instances in the profiles ( 6.000 + ), what are those? Should they worry me?

        • 1. Re: Flash builder profiling: methodClosure
          Nielzz Level 1

          I turned off transparancy of  the main window (in the XML config) and I't down to a nice 0% idle.


          There should really be more warnings about using transparancy if it's this bad.


          Still wondering about the methodClosures ( over 6000) in the profiler...

          • 2. Re: Flash builder profiling: methodClosure
            Douglas McCarroll Level 1

            Reviving this thread...


            I also would love to know what MethodClosure indicates in the profiler.


            I have a somewhat complex application, and am seeing ~14,000 cumulative instances of MethodClosure, which are consuming .7 MB of cumulative memory.


            I've tried googling this and am finding nothing.


            Adobe - is there any documentation for the Profiler that explains stuff like this? The Profiler is a great tool, but there's a fair amount that I still don't understand, even though I've used it a fair amount and invested a lot of time into trying to understand it.





            • 3. Re: Flash builder profiling: methodClosure
              Flex harUI Adobe Employee

              MethodClosures are created for function references including callbacks and calls to addEventListener.  They are fat: one would think they should be about 8 bytes, but they are in the 64 byte to 128 byte range.


              Having 14,000 instances around means that you have a lot of objects listening to other objects.