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 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
