6 Replies Latest reply on May 22, 2013 3:03 AM by pigiuz

    profiling memory: what is Bitmap -> Images ?

    pigiuz Level 1

      Hi guys,

      I'm profiling memory usage of my app and I found out that my allocated bitmapdata objects are not changing but I'm having an uncontrolled sawtooth graph on "Bitmap->Images".

      I'm guessing that is the label for the images loaded by Loader, is this correct? is something else in there?


      if this guess is right, which is the best way to get rid of that memory?

      my app is loading a ton of images, but all that data is stored in preallocated bytearrays using copyPixelsToBytearray api, then I'm disposing the loaded bitmapdata and I'm calling Loader.unload() api.

      am I missing something?

      is there any better way to do this?

      is there any way to control the amount of that memory at runtime? (if my guess is right, should I put in place a bitmapdata bytes size counter from the application start, or there's an api for that?)


      thanx in advance,



        • 1. Re: profiling memory: what is Bitmap -> Images ?
          Michael J.A. Smith Adobe Employee

          You're right that the Images category shows the memory used by images that you load with a Loader (if you embed an image, its memory will be included in the SWF file that it's embedded in, and show up under SWF Files).


          This memory is for the compressed image, though - when the image gets decompressed, a new BitmapData is created, and this will show up in the Bitmap DisplayObjects category in Scout. When you access a BitmapData, you're always accessing the uncompressed image. So my guess as to what's happening is that you're correctly disposing the uncompressed BitmapData, which will get released immediately when you call dispose(). Calling Loader.unload(), however, doesn't immediately dispose of the image you loaded (in its compressed form). Instead, you need to wait for the GC to kick in, and realise that nobody else is referencing the loader/image, so it can reclaim the memory. That's why you're seeing a sawtooth pattern in the Image category.


          As far as I'm aware, there's no way to explicitly reference the raw uncompressed image, so you have to rely on the garbage collector to kick in.


          For controlling Flash Player's memory usage at runtime, the only thing you can do is to stop allocating memory - there's no API to tell Flash Player to not allocate above a certain amount. You can manually keep track of how much memory you're using in the images you load, but you'll have to write your own logic to deal with what happens when you're using too much memory (e.g. stop loading new images).

          • 2. Re: profiling memory: what is Bitmap -> Images ?
            pigiuz Level 1

            Thanx Michael,

            so you're saying that loader class copies the source to a temporary buffer? I'm using loader.loadBytes, is it actually a copyAndLoadBytes?

            • 3. Re: profiling memory: what is Bitmap -> Images ?
              Michael J.A. Smith Adobe Employee

              Yes, if you use Loader.loadBytes, then Flash Player will make an internal copy of the data. This is because it doesn't decompress the data immediately - it'll do it either on demand, when you actually use the image, or asynchronously in the background after loading it, depending on your ImageDecodingPolicy. Since you own the original ByteArray, Flash Player can't assume that it's still around after it's loaded the data (or that you haven't modified it), which is why it has to make a copy.


              Make sure that you don't keep a reference to the original ByteArray after it's loaded, so that the GC can delete it when it's no longer needed.


              Remember that whenever you load an image, you essentially have three copies of the data (although the unneeded copies will be disposed of when the GC sweeps up):


              1) The input data. This is a ByteArray in your case (Loader.loadBytes), but if you use Loader.load it'll be coming over the network, hence the "raw" data at some point is stored in network buffers. In the case of a ByteArray, it's up to you to dereference it so it can be GCed. Flash Player will handle the freeing and/or reuse of network buffers after it's finished downloading.


              2) The loaded data. This is stored internally inside Flash Player, and you can't get at it directly. If you remove all references to the corresponding display object, it'll get GCed.


              3) The (decompressed) visible data. This is what you get if you look at the BitmapData of a display object, or when Flash Player draws an image on the screen. Flash Player tries to be clever about this - if you don't use the decompressed data within a certain time (roughly 10s), Flash Player might GC it to recover memory. If this happens, it'll get decompressed again the next time you need to use it.


              With the exception of a few methods like dispose() on BitmapData, Flash Player doesn't give you direct control over memory management - you have to wait for the GC to kick in. So seeing a sawtooth pattern in memory usage is completely normal. The only time to worry is if the average memory continually creeps up (indicating a leak), or if the GC is taking a lot of time and/or being called very frequently (indicating you have a high churn-rate of objects).

              • 4. Re: profiling memory: what is Bitmap -> Images ?
                pigiuz Level 1

                thank you Michael,

                I think I'll go for a native extension for a better memory management.

                Loader is good enough for a lot of applications but this lack of control on memory is pissing me off :\


                I know that via the new telemetry apis it's possible to send some extra data to scout, but,

                is there a way to mimic the image data on the scout protocol so I can plug in the same slot of the loader without using it and profile the native extension in the same way of loader?

                • 5. Re: profiling memory: what is Bitmap -> Images ?
                  Michael J.A. Smith Adobe Employee

                  That's the trade-off between a GCed language, and one that requires explicit memory management. If you want precise control of your memory, the only thing you can do is to go native - and even then, the exact behaviour depends on the OS, and may not be what you expect.


                  With the Telemetry API, you can send custom data to Scout, but it's not possible to spoof internal metrics from ActionScript. In the future, we might add support for plotting custom graphs in Scout, which would allow you to do what you want.

                  • 6. Re: profiling memory: what is Bitmap -> Images ?
                    pigiuz Level 1

                    thank you a lot for your support Michael.

                    that feature would be great to me