Flash Builder 4 Profiler: how to spot what objects are causing a known memory increase?

后端 未结 2 703
没有蜡笔的小新
没有蜡笔的小新 2020-12-29 11:55

I know profiler questions can be quite general, but here I have a very specific question and example.

I know that in the following code (taken from Joshua\'s questio

2条回答
  •  猫巷女王i
    2020-12-29 12:41

    First, I would look at the Memory Usage panel after playing a bit with the application :

    enter image description here

    Notice the memory increases more and more. There is a "Run Garbage Collector" button that forces the GC. However, when you click on it, the memory doesn't decrease.

    The next step is to identify the culprits. For that, you use the Live Objects panel :

    enter image description here

    It looks like that, appart some Vector instances, everything looks allright. By default, a lot of classes are filtered from the live objects datagrid. Fortunately, one can specify which classes will be displayed and hidden. All classes from the flash.x.x packages are hidden by default. Removing them from the filtered list bring somthing interesting to the table :

    enter image description here

    Notice the Graphics row : 871 instances have been created and they are all still in memory! With that info, you can suppose the Graphics instances are responsible of the slow down of the application. If you also filter out the mx.* classes, you will see there are 871 UIComponents instances. Everytime a UIComponent is created, there is a Graphics object also instancied.

    Final step is to remove each UIComponent once it's no more needed on screen and look if there is any performance improvement.

提交回复
热议问题