http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/ RIAbilitating the Internet with web apps, ria, iphone and ipad apps. Fri, 02 Mar 2012 20:49:59 +0000 hourly 1 http://wordpress.org/?v= http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-74877 Garbage Collection and Flex Event Listeners « Thanks, Mister! Thu, 29 Sep 2011 18:35:44 +0000 http://spreadingfunkyness.com/?p=57#comment-74877 [...] http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/ http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html http://gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html http://www.adobe.com/devnet/flashplayer/articles/resource_management.html Share this:TwitterFacebookLike this:LikeBe the first to like this post. [...] [...] http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/ http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html http://gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html http://www.adobe.com/devnet/flashplayer/articles/resource_management.html Share this:TwitterFacebookLike this:LikeBe the first to like this post. [...]

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-14715 如何彻底销毁一个类 | 傲天翔 の blog Sun, 22 Aug 2010 10:07:21 +0000 http://spreadingfunkyness.com/?p=57#comment-14715 [...] Garbage Collection with Flex and Adobe AIR [...] [...] Garbage Collection with Flex and Adobe AIR [...]

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-13235 Subhash Tue, 29 Jun 2010 14:29:04 +0000 http://spreadingfunkyness.com/?p=57#comment-13235 Thank you, thank you, thank you... :) You are a savior; My memory leak problem of 6 months has been solved... Thank you, thank you, thank you… :)
You are a savior; My memory leak problem of 6 months has been solved…

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10125 lwz7512 Sun, 24 Jan 2010 15:33:12 +0000 http://spreadingfunkyness.com/?p=57#comment-10125 great post,I've translate to chinese: http://www.riameeting.com/node/587 great post,I’ve translate to chinese:
http://www.riameeting.com/node/587

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10066 Cesare Thu, 21 Jan 2010 18:57:42 +0000 http://spreadingfunkyness.com/?p=57#comment-10066 The cache I use is a way to ensure that each renderer has only, at most, 2 references: one in the display tree and one in the cache itself. I got to this solution by experimentation and I solved many of the issues I had when dealing with renderers. The cache I use is a way to ensure that each renderer has only, at most, 2 references: one in the display tree and one in the cache itself. I got to this solution by experimentation and I solved many of the issues I had when dealing with renderers.

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10065 Rob McKeown Thu, 21 Jan 2010 18:48:25 +0000 http://spreadingfunkyness.com/?p=57#comment-10065 So when removing from the cache, how do you ensure that its memory gets freed? It doesn't look like it is doing anything special with the renderers other than store them in a collection. Would cache.removeItemAt(n) free the memory allocated to the renderer and position n? I guess I don't understand why removing an item from the cache would behave any differently than removing from the display list (assuming there are no other references to the renderer). So when removing from the cache, how do you ensure that its memory gets freed? It doesn’t look like it is doing anything special with the renderers other than store them in a collection. Would cache.removeItemAt(n) free the memory allocated to the renderer and position n? I guess I don’t understand why removing an item from the cache would behave any differently than removing from the display list (assuming there are no other references to the renderer).

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10064 Cesare Thu, 21 Jan 2010 18:05:17 +0000 http://spreadingfunkyness.com/?p=57#comment-10064 Beware, removeChild just removes a renderer from the display tree, as explained in the post. This does not ensure it is removed from memory. Before calling removeChild you can call MyRendererCache.setRenderer(...) to give it back and there you can check whether your cache is too big or not: if yes, you can remove some renderer also from the cache. Beware, removeChild just removes a renderer from the display tree, as explained in the post. This does not ensure it is removed from memory. Before calling removeChild you can call MyRendererCache.setRenderer(…) to give it back and there you can check whether your cache is too big or not: if yes, you can remove some renderer also from the cache.

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10061 Rob McKeown Thu, 21 Jan 2010 17:01:17 +0000 http://spreadingfunkyness.com/?p=57#comment-10061 Understood... the way I have implemented this in Klok is that the container manages the renderers by doing basically what your cache does so that when the data provider changes, no new renderers are created unless there weren't enough. However, if the new data provider has less items, then I remove the child renderers using removeChild. I would like to ensure some way of efficiently freeing their memory so that I don't have the problem you describe. Understood… the way I have implemented this in Klok is that the container manages the renderers by doing basically what your cache does so that when the data provider changes, no new renderers are created unless there weren’t enough. However, if the new data provider has less items, then I remove the child renderers using removeChild. I would like to ensure some way of efficiently freeing their memory so that I don’t have the problem you describe.

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10060 Cesare Thu, 21 Jan 2010 16:49:00 +0000 http://spreadingfunkyness.com/?p=57#comment-10060 @Rob The cache prevents them from being collected, but is also establishes a limit: if you loaded 20-30-10 items your cache length will be 30. With no cache you might have, in the worst case, 60 renderers. If you have an application with high variability (alternate loading of many and few data) it is better to have a policy in the setter, as explained above. In the "normal case" it depends on the implementation: e.g. if you use a Repeater component you can have a look at the generated code, if you code it your own you are responsible for that. My solution is just a way to have a controllable "centralized" mechanism to generate/delete renderers, so if there are issues about memory I know where to look in the code. @Rob The cache prevents them from being collected, but is also establishes a limit: if you loaded 20-30-10 items your cache length will be 30. With no cache you might have, in the worst case, 60 renderers.
If you have an application with high variability (alternate loading of many and few data) it is better to have a policy in the setter, as explained above.
In the “normal case” it depends on the implementation: e.g. if you use a Repeater component you can have a look at the generated code, if you code it your own you are responsible for that. My solution is just a way to have a controllable “centralized” mechanism to generate/delete renderers, so if there are issues about memory I know where to look in the code.

]]> http://spreadingfunkyness.com/garbage-collection-with-flex-and-adobe-air/comment-page-1/#comment-10059 Cesare Thu, 21 Jan 2010 16:32:52 +0000 http://spreadingfunkyness.com/?p=57#comment-10059 @Rob Thanks for your question. This depends on the policy of the cache setter. Instead of just adding the "used" renderer to the cache you can do a check on the length of the cache itself and, if greater than a given threshold, you can avoid to add it. To me, the only way to find the "best" value of the threshold is by experimentation, for it depends on many factors: the application, the number/frequency of queries, the number of returned results, the complexity of the renderer... @Rob Thanks for your question. This depends on the policy of the cache setter. Instead of just adding the “used” renderer to the cache you can do a check on the length of the cache itself and, if greater than a given threshold, you can avoid to add it. To me, the only way to find the “best” value of the threshold is by experimentation, for it depends on many factors: the application, the number/frequency of queries, the number of returned results, the complexity of the renderer…

]]>