On my project, I was using De MonsterDebugger (DMD) (great tool, easy to implement, but can get heavy if you don't have a lot of RAM - peaks at about 150MB for me, which can hurt because I'm running on only 2 GB). In my project, I am rolling over canvases, and on each rollover, the background of the application should have its images change. My initial development had me doing this by changing the style of the Application (application.setStyle("backgroundImage",assets/myNewImg)). And to make the transition smooth, I had a second Image that I was using on top of the background, but underneath all the other components (z level = lowest possible).
The problem quickly became clear (even more so w/ DMD because I could see why my computer would stop responding when debugging, i.e. my RAM usage was spiking). In the last several days I have been reading about garbage collection (GC) and how it seems to act on its own accord. It was happening w/ my app, which would always return to about 40MB in runtime, but could (and often did) spike upwards of 250MB!!! All that for a single swf file running in Safari. I checked my objects, commented out different things (including custom turtle border graphics), and went through item by item that could've ran up so much RAM.
Finally it came back to my images being swapped in and out. I thought the image class could handle changing sources quickly, but it turns out, that was eating huge resources to render the image (all while doing some lightweight tweening). I tried my best to build this application to follow OOP and reusability as best as I could. The data source (an xml config file) is what drives the layout and information of the app, so I wanted to avoid embedding anything that needed to be called up explicitly w/ a case/if. But alas, I could only do so much before I had to make some exceptions in my class and embed the background images, and use a case statement to assign it correctly on hover. Once here, and once I realized that changing two background images (one stacked on the other to allow me to transition smoothly - read fade - meant I needed two images).
My app now only spikes at about 68MB, no matter how many transitions I make, and I don't have to try to force GC (which eventually happens during idle time). The last thing I think I'd like to try is possibly improving the cpu performance and keeping the fan from getting hot by adjusting frame rate, but for now, I'm happy that my app doesn't spike so much anymore.
No comments:
Post a Comment