Tim - actually strong references _can_cause memory leaks. would you consider either of the following lines bad coding?
Application.application.addEventListener(Event.ENTER_FRAME, onEnterFrame); Application.application.addEventListener(Event.ENTER_FRAME, onEnterFrame, false, 0, true); Depends on the context you say? Partially. the big issue is the AVM2 memory allocation/release cycle of which only a portion is published. It is well known that the Flash Player uses a 'greedy' memory allocation model with a sometimes 'lazy' garbage collection. so, I beg to differ with your inference that poor system performance is a result of "bad coding and lack of understanding of components" when it is more a product of 'things unknown' that necessitates experimentation to find a performance balance. Jun Heider did a fantastic presentation on this very issue at 360|Flex in Atlanta. Essentially. The Flash Player garbage collectZOR will either use deferred reference counting or mark and sweep (or perhaps both) to find things that need cleaning up. If you have used a *strong* reference on an Object it will be passed over until its reference count = 0. *Weak* references are not included in a deferred reference cycle (since they probably don't have any references and would always be marked for collection). This is where things get juicy. Mark and sweep traverses the application space to 'mark' any Objects that are not reachable via some sort of parent-child relationship. Even if you are cleaning up after yourself you may find that the Flash Player is aggressively holding onto memory. which is what it was designed to do (see greedy above). So. some memory problems may be averteted - while others will be/are a burden you will need to deal with. Rick Winscot From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tim Rowe Sent: Tuesday, July 15, 2008 1:17 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] When not to use weak references? Strong references don't cause memory leaks, bad coding and lack of understanding of components causes memory leaks. This seems to be a topic a lot like pointers all over again 30 years later, WRT how many people understand them (or don't). I actually agree you'd normally want a strong reference with a timer, if it's going to continue to live. Admittedly in that area I'm only regurgitating what I've told (by many) and understood, as I've not yet had to implement any timer code (or much in Flex at all) - but this is a topic I'm keen to try to get right and understand from the start before I get too deep in to things. On timers and singletons there's something going on there that I haven't quite done enough research into, but in what research I have done I I can't seem to find much that says a strong reference should be used on these kinds of objects. Like I said, feel free to correct me on anything here. Personally I'd be happy to just do away with garbage collection altogether - that would 'solve' the problem ;) I must admit I'm finding a lot of anti-patterns and bad implementations/ideas in the Flex world so far. --Tim Rowe _____ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Gold Sent: Tuesday, 15 July 2008 2:58 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] When not to use weak references? I would agree that's not a best practice for writing timer code, just the quickest example I could think of. When people read about how bad strong references are and how they cause memory leaks, they tend to make EVERYTHING weak which can lead to some nasty problems. Since you can't control the timing or depend on garbage collection, 95% of the time the listener could get called, the other 5% the target object could be GCd before the listener ever runs. On Mon, Jul 14, 2008 at 11:49 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: Why use weak references on singletons or things that are going to live the life of the application? Not saying it's wrong, just interested in the logic. The timer code above is a great example of when you need a strong reference, but a nasty example of how to use a timer! I *really* don't like the idea of the Timer instance only being available within the event handlers :) A listener will always get called if the object it's listening to is still around though right? Weak reference or no? -Josh On Tue, Jul 15, 2008 at 2:43 PM, Tim Rowe <[EMAIL PROTECTED]> wrote: Use strong references when you're adding an event listener to the same instance dispatching an event. If it's an anonymous function, you need to use a strong reference. Also, use strong references when you want speed - weak references are slower. Always use weak references when dealing with singletons (Cairngorm's event dispatcher is a singleton, hence, always use with Cairngorm), or objects that live the life of the application. This includes timers waiting on call backs also. Not always true but if you have an object you intend to never have destroyed, but it may also be perfectly safe to use strong references. Keep in mind though that using a weak reference on, say, an event listener where a strong one was required may result in things like that listener not getting called. I'm only new to Flex, but this is as I understand it, and no doubt I've missed a few things here and there. --Tim Rowe _____ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Boon Chew Sent: Tuesday, 15 July 2008 2:08 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] When not to use weak references? Hi all, I have read posts that preached the goodness of weak references for event listening, but have not read anything that suggests when you should use strong reference over the weak one, and the down side to using weak references. Any ideas when being weak is not bad thing? :) - boon -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
