[flexcoders] Memory leaks
Hi I created an air application with a schedule. To populate this schedule with appointment, I launch an httpservice and result is use to populate an array collection. Each time user change week, a new request is sending. The variable myDataCalendar (array collection) is defined as [Bindable] private var myDataCalendar :ArrayCollection; I try to reuse the same ArrayCollection, but I think making a mistake because memory increase each time, and garbage collector seems not working! myDataCalendar = new ArrayCollection(); myDataCalendar.refresh(); So can you help me to understand memory leak. Best regards
[flexcoders] memory leaks and activation-objects
I've been wrestling with memory leaks and the FB4 profiler and lately have been trying to understand activation-objects and their relationship to GC because the vast majority (often all) of the references the profiler tells me an object has keeping it in memory come from activation objects. While researching this I came across a note from Alex Harui saying I've never seen an activation object cause a leak but other things I've read seem to suggest they can. (Certainly the profiler would lead me to believe it.) Can anybody enlighten me? Or just point me to the place to read documentation on the subject that is up-to-date? Half of what I've read about activation objects appears to be from earlier versions of ActionScript so I'm not sure what to believe. If an activation object can cause a memory leak, I'd like to understand how. I may not have a firm grasp of the lifecycle of an activation object but I thought it would no longer be accessible from the GC root after the function it's created for finishes executing. Any help or pointers would be greatly appreciated. Lew
Re: [flexcoders] memory leaks and activation-objects
AFAIK, they do not cause leaks. If you show some data or a simple test case that indicates that they are, I will try to take a look. On 8/30/10 8:36 AM, lew.miller lew.mil...@gmail.com wrote: I've been wrestling with memory leaks and the FB4 profiler and lately have been trying to understand activation-objects and their relationship to GC because the vast majority (often all) of the references the profiler tells me an object has keeping it in memory come from activation objects. While researching this I came across a note from Alex Harui saying I've never seen an activation object cause a leak but other things I've read seem to suggest they can. (Certainly the profiler would lead me to believe it.) Can anybody enlighten me? Or just point me to the place to read documentation on the subject that is up-to-date? Half of what I've read about activation objects appears to be from earlier versions of ActionScript so I'm not sure what to believe. If an activation object can cause a memory leak, I'd like to understand how. I may not have a firm grasp of the lifecycle of an activation object but I thought it would no longer be accessible from the GC root after the function it's created for finishes executing. Any help or pointers would be greatly appreciated. Lew -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
[flexcoders] Memory leaks?
When I load different modules, I notice a large decrease in performance.
The thing is, there are only 2 modules that get loaded, and the user
can go back and forth.
startup = module 1
click link to get to module 2
click 'back' button to get back to module 1
click link to get ot module 2
click 'back' to get to module 1
etc...
I am actually loading the module everytime it is being clicked,
instead of caching it, should I be caching it?
Is there a better way to load the modules, rather than like this:
private function loadModule( url:String ):void {
moduleLoader.url = url;
moduleLoader.loadModule();
}
!-- MXML LOOKS LIKE THIS --
mx:ModuleLoader id=moduleLoader top=43 left=0 visible=false /
lemme know!
RE: [flexcoders] Memory leaks?
Cache them if you want, but that might mean a higher total memory usage. It is
always a trade-off.
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf
Of tchredeemed
Sent: Friday, January 16, 2009 12:04 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Memory leaks?
When I load different modules, I notice a large decrease in performance.
The thing is, there are only 2 modules that get loaded, and the user
can go back and forth.
startup = module 1
click link to get to module 2
click 'back' button to get back to module 1
click link to get ot module 2
click 'back' to get to module 1
etc...
I am actually loading the module everytime it is being clicked,
instead of caching it, should I be caching it?
Is there a better way to load the modules, rather than like this:
private function loadModule( url:String ):void {
moduleLoader.url = url;
moduleLoader.loadModule();
}
!-- MXML LOOKS LIKE THIS --
mx:ModuleLoader id=moduleLoader top=43 left=0 visible=false /
lemme know!
[flexcoders] Memory leaks in Flex SDK
Hi all, I know this is a multennial subject, but I just checked Adobe's JIRA and found three confirmed memory leaks in the Flex SDK :( They are: + Memory leak in SWFLoader: https://bugs.adobe.com/jira/browse/SDK-18076 + BindingUtils don't use weak event listeners, creating potential memory leaks: https://bugs.adobe.com/jira/browse/SDK-14891 + Flash Components break GC in FLex (while loaded at runtime): https://bugs.adobe.com/jira/browse/SDK-13612 AFAIK, a well modularised application has to make use of SWFLoader for dynamic linking, so that's a big worry as my app is designed to run continuously in the background. The second two are slated to be fixed in Flex Gumbo (not really imminent but somewhat reassuring), however Adobe are particularly quiet about the SWFLoader problem. Anyone know of any workaround for these issues (esp. SWFLoader)? Cheers, Jules
RE: [flexcoders] Memory leaks in Flex SDK
SDK-18076 hasn't got enough votes to go to engineering for investigation. Most of the time, we find a bug in the user app. Every once in a while we find something we missed, but it isn't SWFLoader, it is some control somewhere that doesn't clean up. AFAIK, several folks are happily deployed using SWFLoader or ModuleLoader. Most recently, we learned that some SWFs don't fully unload their debug info, invalidating the profilers results. I always advise using the profiler to eliminate the odds of there actually being a leak, but then, export your swfs for release builds and use a release player and see what happens. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jules Suggate Sent: Tuesday, November 25, 2008 1:02 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks in Flex SDK Hi all, I know this is a multennial subject, but I just checked Adobe's JIRA and found three confirmed memory leaks in the Flex SDK :( They are: + Memory leak in SWFLoader: https://bugs.adobe.com/jira/browse/SDK-18076 + BindingUtils don't use weak event listeners, creating potential memory leaks: https://bugs.adobe.com/jira/browse/SDK-14891 + Flash Components break GC in FLex (while loaded at runtime): https://bugs.adobe.com/jira/browse/SDK-13612 AFAIK, a well modularised application has to make use of SWFLoader for dynamic linking, so that's a big worry as my app is designed to run continuously in the background. The second two are slated to be fixed in Flex Gumbo (not really imminent but somewhat reassuring), however Adobe are particularly quiet about the SWFLoader problem. Anyone know of any workaround for these issues (esp. SWFLoader)? Cheers, Jules
Re: [flexcoders] Memory leaks in Flex SDK
I'll second that. I've found the profiler hard to rely upon. Running my app in a browser alongside WSMonitor seems more convincing to me, but that might be because it gives me the answer I expect want (ie, no leaks). Guy On 26/11/2008, at 3:08 PM, Alex Harui wrote: SDK-18076 hasn’t got enough votes to go to engineering for investigation. Most of the time, we find a bug in the user app. Every once in a while we find something we missed, but it isn’t SWFLoader, it is some control somewhere that doesn’t clean up. AFAIK, several folks are happily deployed using SWFLoader or ModuleLoader. Most recently, we learned that some SWFs don’t fully unload their debug info, invalidating the profilers results. I always advise using the profiler to eliminate the odds of there actually being a leak, but then, export your swfs for release builds and use a release player and see what happens. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jules Suggate Sent: Tuesday, November 25, 2008 1:02 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks in Flex SDK Hi all, I know this is a multennial subject, but I just checked Adobe's JIRA and found three confirmed memory leaks in the Flex SDK :( They are: + Memory leak in SWFLoader: https://bugs.adobe.com/jira/browse/SDK-18076 + BindingUtils don't use weak event listeners, creating potential memory leaks: https://bugs.adobe.com/jira/browse/SDK-14891 + Flash Components break GC in FLex (while loaded at runtime): https://bugs.adobe.com/jira/browse/SDK-13612 AFAIK, a well modularised application has to make use of SWFLoader for dynamic linking, so that's a big worry as my app is designed to run continuously in the background. The second two are slated to be fixed in Flex Gumbo (not really imminent but somewhat reassuring), however Adobe are particularly quiet about the SWFLoader problem. Anyone know of any workaround for these issues (esp. SWFLoader)? Cheers, Jules
[flexcoders] Memory Leaks... Cumulative Memory and Memory.
Hi everyone, I think I'm having some issues with memory leaks. The memory of my Cumulative Memory and of my Memory keep increasing. When I unload modules, the memory doesn't drop and if I reload the modules, the memory keeps climbing... When I use the import command (ie:import mx.controls.Alert;), do I need to unload the mx.controls.Alert when I unload my module? If so, how do I do this? If not, why does my memory keep climbing when I unload a module and reload it? Shouldn't it drop and then climb back? Thanks. -David
Re: [flexcoders] Memory Leaks... Cumulative Memory and Memory.
I'm interested in knowing more about this too...I have an app that seems to cause the browser's memory to increase steadily over the course of several hours. However, if I run WSMonitor alongside it, it says the memory usage of my app *doesn't* increase overall (though it fluctuates between 130 and 150mb - it loads data continuously so this is expected). http://www.websector.de/blog/2007/10/01/detecting-memory-leaks-in-flash-or-flex-applications-using-wsmonitor/ So my question is, should I trust WSMonitor? Or is the browser right and I have a memory leak? This has been observed in Firefox on Mac OS, as well as Chrome and FF on Windows. Guy On 20/11/2008, at 7:29 AM, sailorsea21 wrote: Hi everyone, I think I'm having some issues with memory leaks. The memory of my Cumulative Memory and of my Memory keep increasing. When I unload modules, the memory doesn't drop and if I reload the modules, the memory keeps climbing... When I use the import command (ie:import mx.controls.Alert;), do I need to unload the mx.controls.Alert when I unload my module? If so, how do I do this? If not, why does my memory keep climbing when I unload a module and reload it? Shouldn't it drop and then climb back? Thanks. -David
Re: [flexcoders] Memory Leaks... Cumulative Memory and Memory.
That is the normal behaviour of the GC. It only runs, if it is necessary. You could try loading/unloading your module 1000 times to see if you really have a leak. r. On Wed, Nov 19, 2008 at 9:29 PM, sailorsea21 [EMAIL PROTECTED] wrote: Hi everyone, I think I'm having some issues with memory leaks. The memory of my Cumulative Memory and of my Memory keep increasing. When I unload modules, the memory doesn't drop and if I reload the modules, the memory keeps climbing... When I use the import command (ie:import mx.controls.Alert;), do I need to unload the mx.controls.Alert when I unload my module? If so, how do I do this? If not, why does my memory keep climbing when I unload a module and reload it? Shouldn't it drop and then climb back? Thanks. -David
RE: [flexcoders] Memory Leaks... Cumulative Memory and Memory.
Use the profiler to check for memory leaks. If you don't see any obvious ones, then export a release build and use a release player and watch memory with ProcessMonitor. There's been reports that debuggable modules do not completely unload, especially in FP9 From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Guy Morton Sent: Wednesday, November 19, 2008 12:44 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Memory Leaks... Cumulative Memory and Memory. I'm interested in knowing more about this too...I have an app that seems to cause the browser's memory to increase steadily over the course of several hours. However, if I run WSMonitor alongside it, it says the memory usage of my app *doesn't* increase overall (though it fluctuates between 130 and 150mb - it loads data continuously so this is expected). http://www.websector.de/blog/2007/10/01/detecting-memory-leaks-in-flash-or-flex-applications-using-wsmonitor/ So my question is, should I trust WSMonitor? Or is the browser right and I have a memory leak? This has been observed in Firefox on Mac OS, as well as Chrome and FF on Windows. Guy On 20/11/2008, at 7:29 AM, sailors! ea21 wrote: Hi everyone, I think I'm having some issues with memory leaks. The memory of my Cumulative Memory and of my Memory keep increasing. When I unload modules, the memory doesn't drop and if I reload the modules, the memory keeps climbing... When I use the import command (ie:import mx.controls.Alert;), do I need to unload the mx.! controls.Alert when I unload my module? If so, how do! I do th is? If not, why does my memory keep climbing when I unload a module and reload it? Shouldn't it drop and then climb back? Thanks. -David
[flexcoders] Memory leaks in a asyncronic operation
Hello, i've been searching for a while to a solution to this problem, and i've been trying myself, with no succeed. The problem is this, i'm encoding to JPEG six bitmap captures from a webcam stream in a video component. Up to here, is no problem. But if I used the native class to encode (mx.graphics.codec.JPEGEncoder) the AIR application hang for 2 minutes processing the images. In these case at the end of the process i call a function to free up the memory, and everything works fine. The problem is that i'm using a modified class to encode (http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-asynchronous-jpeg-encoder/) . The benefit is that i can show a progressbar showing the encoding process. But the only problem that i have is that, at the end of the process, i have memory hang up... i've been reading that these may occur without a proper care in the events listeners. Sory about my english, is not ma native language, and thanks in advance for your time and patience.
RE: [flexcoders] Memory leaks in a asyncronic operation
The Flex3 Profiler can help you find memory leaks From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of cavi21 Sent: Monday, June 02, 2008 2:10 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks in a asyncronic operation Hello, i've been searching for a while to a solution to this problem, and i've been trying myself, with no succeed. The problem is this, i'm encoding to JPEG six bitmap captures from a webcam stream in a video component. Up to here, is no problem. But if I used the native class to encode (mx.graphics.codec.JPEGEncoder) the AIR application hang for 2 minutes processing the images. In these case at the end of the process i call a function to free up the memory, and everything works fine. The problem is that i'm using a modified class to encode (http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as ynchronous-jpeg-encoder/ http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as ynchronous-jpeg-encoder/ ) . The benefit is that i can show a progressbar showing the encoding process. But the only problem that i have is that, at the end of the process, i have memory hang up... i've been reading that these may occur without a proper care in the events listeners. Sory about my english, is not ma native language, and thanks in advance for your time and patience.
Re: [flexcoders] Memory leaks
Alex, I appreciate your reply but I still think there's something wrong regarding memory. I'm sending you an application that reproduces the situation I started my earlier post with. Flex does not releases all the memory it takes, even inducing garbage collection as I show in the demo application. If you repeat the experience over and over you will see that the memory lost is not likely to get back. So what is this? What can I do about it? On 8/25/07, Alex Harui [EMAIL PROTECTED] wrote: There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems of this nature and post examples on this forum as often there can be a misunderstanding of how memory management works in Flash/Flex. The second kind of issues is sort of a fact-of-life for Flex. The first module to introduce shared code via Styles or Managers must remain in memory to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. The blog article includes an example of a way to deal with this situation, although often the easiest way is just to include all managers in the main app, and bring in styles via runtime CSS. As you'll see in the article, browser memory management has little to do with it. It simply has to do with how GC works (described further elsewhere on my blog) and how styles and singleton managers are shared. Any memory changes when minimizing is probably due to IE releasing its own browser resources, although the player may release some at that time as well. If you have further questions, this forum should be able to help you out. In the future, please ask sooner before you spend time creating eloborate infrastructures. -Alex -- *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *André Rodrigues Pena *Sent:* Saturday, August 25, 2007 10:44 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Memory leaks Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support between modules. It's not natural. It seems that the browser may have a great part of the blame. They realized, for instance, that Internet Explorer releases the memory when the window is minimized and FireFox doesn't. I'm here to ask what else can be done regarding memory issues. And how you professionals have dealt with it. Thanks -- André Rodrigues Pena -- André Rodrigues Pena
Re: [flexcoders] Memory leaks - binding to e4x XML?
Alex - No feathers ruffled at all... I just wanted to make it clear that I take the accuracy of the information very seriously. My goal is to help others avoid the types of problems that I ran into. When more accurate information becomes available I will be sure to update as appropriate. In the mean time, I will attempt to find time to write a simple application that demonstrates this issue clearly. Glad you are planning to look into it too :) Thanks Scott Alex Harui wrote: Scott, I don't doubt you saw what you saw, and everything you've posted could be true (naturally I hope it isn't cuz that'll mean we don't have a bug there). My frustration comes from the following: In your post you state that XMLListColleciton leaked less. In theory, dumping e4x into a datagrid is the same as XMLLIstCollection since we just wrap the xml in a XMLListCollection. You also state a theory that XMLListCollection convert xml to objects, which is misleading to post since it isn't quite true These things make your whole post suspect. You may in fact have some scenario where XMLListCollection behaves differently from straght e4x, but normally it shouldn't. I often miss threads on FlexCoders since we're pretty busy and I was away for a couple of weeks, but did the memory leak aspect of this issue get discussed on this forum? Is there a bug filed for this issue? It might be in process and I haven't seen it yet. Usually, these kinds of issues catch my attention. I'm generally more than willing to squeeze some time out of my day to try to help with investigating things like this and love it when, once we figure out the issue, you post blog articles that help the community since it saves me time and makes one more person out there who can help others in similar situations. However, I would much prefer to work with you before you post so we get the right information out there. IMHO, memory usage is a trcky topic and easy to either misdiagnose, and/or offer up solutions/workarounds that either don't really work, or aren't optimal. Sorry, if I ruffled feathers, -Alex *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Scott - FastLane *Sent:* Saturday, August 25, 2007 1:33 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Memory leaks - binding to e4x XML? Alex - That is my posting, and I would hate for it to be misinformation in any way. If your research turns up no evidence that I am correct then I will endeavor to re-create my problem in a sample application that I can send along to you for inspection. If I cannot successfully demonstrate that binding to e4x is leaking memory I will be more than happy to withdraw my posting. However, I should note, that I had a friend who was working on a similar application (datagrid bound directly to e4x)... knowing this I told him about my experiences. He then added memory logging to his application. Although his leak was less rapid than mine (he says with 1 minute refreshes he lost 1M or so per hour) he also saw the issue. He then changed his application over to strongly typed objects and noted that his memory leak had also been resolved. It was at this point that I decided to publish the post in case it might help others. Scott Alex Harui wrote: I thought it was a performance issue only. I do expect sealed classes to perform better than XMLLIstCollection (which does not convert to object). I'll have to investigate further. Always frustrating when misinformation get out there... *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Tracy Spratt *Sent:* Saturday, August 25, 2007 11:47 AM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Memory leaks - binding to e4x XML? I came across this article, wherein the author alleges that binding to e4x XML objects cause memory leaks: http://blog.fastlanesw.com/?p=14 http://blog.fastlanesw.com/?p=14 His arguments / findings, seemed well reasoned and supported, and I do not have the background to refute them. Perhaps someone here might discuss this. Tracy *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Alex Harui *Sent:* Saturday, August 25, 2007 2:21 PM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Memory leaks There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem
[flexcoders] Memory leaks
Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support between modules. It's not natural. It seems that the browser may have a great part of the blame. They realized, for instance, that Internet Explorer releases the memory when the window is minimized and FireFox doesn't. I'm here to ask what else can be done regarding memory issues. And how you professionals have dealt with it. Thanks -- André Rodrigues Pena
RE: [flexcoders] Memory leaks
There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems of this nature and post examples on this forum as often there can be a misunderstanding of how memory management works in Flash/Flex. The second kind of issues is sort of a fact-of-life for Flex. The first module to introduce shared code via Styles or Managers must remain in memory to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. The blog article includes an example of a way to deal with this situation, although often the easiest way is just to include all managers in the main app, and bring in styles via runtime CSS. As you'll see in the article, browser memory management has little to do with it. It simply has to do with how GC works (described further elsewhere on my blog) and how styles and singleton managers are shared. Any memory changes when minimizing is probably due to IE releasing its own browser resources, although the player may release some at that time as well. If you have further questions, this forum should be able to help you out. In the future, please ask sooner before you spend time creating eloborate infrastructures. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of André Rodrigues Pena Sent: Saturday, August 25, 2007 10:44 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support between modules. It's not natural. It seems that the browser may have a great part of the blame. They realized, for instance, that Internet Explorer releases the memory when the window is minimized and FireFox doesn't. I'm here to ask what else can be done regarding memory issues. And how you professionals have dealt with it. Thanks -- André Rodrigues Pena
RE: [flexcoders] Memory leaks - binding to e4x XML?
I came across this article, wherein the author alleges that binding to e4x XML objects cause memory leaks: http://blog.fastlanesw.com/?p=14 His arguments / findings, seemed well reasoned and supported, and I do not have the background to refute them. Perhaps someone here might discuss this. Tracy From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Saturday, August 25, 2007 2:21 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Memory leaks There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems of this nature and post examples on this forum as often there can be a misunderstanding of how memory management works in Flash/Flex. The second kind of issues is sort of a fact-of-life for Flex. The first module to introduce shared code via Styles or Managers must remain in memory to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. The blog article includes an example of a way to deal with this situation, although often the easiest way is just to include all managers in the main app, and bring in styles via runtime CSS. As you'll see in the article, browser memory management has little to do with it. It simply has to do with how GC works (described further elsewhere on my blog) and how styles and singleton managers are shared. Any memory changes when minimizing is probably due to IE releasing its own browser resources, although the player may release some at that time as well. If you have further questions, this forum should be able to help you out. In the future, please ask sooner before you spend time creating eloborate infrastructures. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of André Rodrigues Pena Sent: Saturday, August 25, 2007 10:44 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support between modules. It's not natural. It seems that the browser may have a great part of the blame. They realized, for instance, that Internet Explorer releases the memory when the window is minimized and FireFox doesn't. I'm here to ask what else can be done regarding memory issues. And how you professionals have dealt with it. Thanks -- André Rodrigues Pena
RE: [flexcoders] Memory leaks - binding to e4x XML?
I thought it was a performance issue only. I do expect sealed classes to perform better than XMLLIstCollection (which does not convert to object). I'll have to investigate further. Always frustrating when misinformation get out there... From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Spratt Sent: Saturday, August 25, 2007 11:47 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Memory leaks - binding to e4x XML? I came across this article, wherein the author alleges that binding to e4x XML objects cause memory leaks: http://blog.fastlanesw.com/?p=14 http://blog.fastlanesw.com/?p=14 His arguments / findings, seemed well reasoned and supported, and I do not have the background to refute them. Perhaps someone here might discuss this. Tracy From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Saturday, August 25, 2007 2:21 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Memory leaks There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems of this nature and post examples on this forum as often there can be a misunderstanding of how memory management works in Flash/Flex. The second kind of issues is sort of a fact-of-life for Flex. The first module to introduce shared code via Styles or Managers must remain in memory to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. The blog article includes an example of a way to deal with this situation, although often the easiest way is just to include all managers in the main app, and bring in styles via runtime CSS. As you'll see in the article, browser memory management has little to do with it. It simply has to do with how GC works (described further elsewhere on my blog) and how styles and singleton managers are shared. Any memory changes when minimizing is probably due to IE releasing its own browser resources, although the player may release some at that time as well. If you have further questions, this forum should be able to help you out. In the future, please ask sooner before you spend time creating eloborate infrastructures. -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of André Rodrigues Pena Sent: Saturday, August 25, 2007 10:44 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Memory leaks Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support between modules. It's not natural. It seems that the browser may have a great part of the blame. They realized, for instance, that Internet Explorer releases the memory when the window is minimized and FireFox doesn't. I'm here to ask what else can be done regarding memory issues. And how you professionals have dealt with it. Thanks -- André Rodrigues Pena
Re: [flexcoders] Memory leaks - binding to e4x XML?
Alex - That is my posting, and I would hate for it to be misinformation in any way. If your research turns up no evidence that I am correct then I will endeavor to re-create my problem in a sample application that I can send along to you for inspection. If I cannot successfully demonstrate that binding to e4x is leaking memory I will be more than happy to withdraw my posting. However, I should note, that I had a friend who was working on a similar application (datagrid bound directly to e4x)... knowing this I told him about my experiences. He then added memory logging to his application. Although his leak was less rapid than mine (he says with 1 minute refreshes he lost 1M or so per hour) he also saw the issue. He then changed his application over to strongly typed objects and noted that his memory leak had also been resolved. It was at this point that I decided to publish the post in case it might help others. Scott Alex Harui wrote: I thought it was a performance issue only. I do expect sealed classes to perform better than XMLLIstCollection (which does not convert to object). I'll have to investigate further. Always frustrating when misinformation get out there... *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Tracy Spratt *Sent:* Saturday, August 25, 2007 11:47 AM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Memory leaks - binding to e4x XML? I came across this article, wherein the author alleges that binding to e4x XML objects cause memory leaks: http://blog.fastlanesw.com/?p=14 http://blog.fastlanesw.com/?p=14 His arguments / findings, seemed well reasoned and supported, and I do not have the background to refute them. Perhaps someone here might discuss this. Tracy *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Alex Harui *Sent:* Saturday, August 25, 2007 2:21 PM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Memory leaks There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems of this nature and post examples on this forum as often there can be a misunderstanding of how memory management works in Flash/Flex. The second kind of issues is sort of a fact-of-life for Flex. The first module to introduce shared code via Styles or Managers must remain in memory to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. The blog article includes an example of a way to deal with this situation, although often the easiest way is just to include all managers in the main app, and bring in styles via runtime CSS. As you'll see in the article, browser memory management has little to do with it. It simply has to do with how GC works (described further elsewhere on my blog) and how styles and singleton managers are shared. Any memory changes when minimizing is probably due to IE releasing its own browser resources, although the player may release some at that time as well. If you have further questions, this forum should be able to help you out. In the future, please ask sooner before you spend time creating eloborate infrastructures. -Alex *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *André Rodrigues Pena *Sent:* Saturday, August 25, 2007 10:44 AM *To:* flexcoders@yahoogroups.com *Subject:* [flexcoders] Memory leaks Hi all, It might be a well-known that Flex has several memory issues. It doesn't completely free the memory of the components you add runtime, when you remove them from their containers, and when it comes to large-scale applications, this is a huge concern. The way my co-workers found to pass by it was to create a Javascript/Flex framework to allow Flex to load modules in separate HTML frames and provide communication between them. So, when a module gets out of scene, the browser frees the entire SWF. But this approach limits the user interaction like drag-n-drop support
RE: [flexcoders] Memory leaks - binding to e4x XML?
Scott, I don't doubt you saw what you saw, and everything you've posted could be true (naturally I hope it isn't cuz that'll mean we don't have a bug there). My frustration comes from the following: In your post you state that XMLListColleciton leaked less. In theory, dumping e4x into a datagrid is the same as XMLLIstCollection since we just wrap the xml in a XMLListCollection. You also state a theory that XMLListCollection convert xml to objects, which is misleading to post since it isn't quite true These things make your whole post suspect. You may in fact have some scenario where XMLListCollection behaves differently from straght e4x, but normally it shouldn't. I often miss threads on FlexCoders since we're pretty busy and I was away for a couple of weeks, but did the memory leak aspect of this issue get discussed on this forum? Is there a bug filed for this issue? It might be in process and I haven't seen it yet. Usually, these kinds of issues catch my attention. I'm generally more than willing to squeeze some time out of my day to try to help with investigating things like this and love it when, once we figure out the issue, you post blog articles that help the community since it saves me time and makes one more person out there who can help others in similar situations. However, I would much prefer to work with you before you post so we get the right information out there. IMHO, memory usage is a trcky topic and easy to either misdiagnose, and/or offer up solutions/workarounds that either don't really work, or aren't optimal. Sorry, if I ruffled feathers, -Alex From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Scott - FastLane Sent: Saturday, August 25, 2007 1:33 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Memory leaks - binding to e4x XML? Alex - That is my posting, and I would hate for it to be misinformation in any way. If your research turns up no evidence that I am correct then I will endeavor to re-create my problem in a sample application that I can send along to you for inspection. If I cannot successfully demonstrate that binding to e4x is leaking memory I will be more than happy to withdraw my posting. However, I should note, that I had a friend who was working on a similar application (datagrid bound directly to e4x)... knowing this I told him about my experiences. He then added memory logging to his application. Although his leak was less rapid than mine (he says with 1 minute refreshes he lost 1M or so per hour) he also saw the issue. He then changed his application over to strongly typed objects and noted that his memory leak had also been resolved. It was at this point that I decided to publish the post in case it might help others. Scott Alex Harui wrote: I thought it was a performance issue only. I do expect sealed classes to perform better than XMLLIstCollection (which does not convert to object). I'll have to investigate further. Always frustrating when misinformation get out there... From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Spratt Sent: Saturday, August 25, 2007 11:47 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Memory leaks - binding to e4x XML? I came across this article, wherein the author alleges that binding to e4x XML objects cause memory leaks: http://blog.fastlanesw.com/?p=14 http://blog.fastlanesw.com/?p=14 His arguments / findings, seemed well reasoned and supported, and I do not have the background to refute them. Perhaps someone here might discuss this. Tracy From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Saturday, August 25, 2007 2:21 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Memory leaks There are two major memory usage scenarios in Flex. One involves creating a new instance of a component, displaying, and later destroying it. The other involves bringing in one or more classes of components in a module and trying to get rid of that module later when its classes are no longer needed. Honestly, I don't know of any issues of the first kind at this point. A major problem with ViewStack related components was addressed in Hotfix2, and a DateField issue was either addressed in the same hotfix, or a workaround was provided and the issue fixed for Moxie. A recent issue with Menus was fixed for Moxie and a workaround was provided. I'm sure there are still issues out there, and they should be filed as bugs so we can investigate and fix them. I also encourage you to try to isolate problems
