Hi Alex, Thanks for responding. Should this be tracked as a bug? I think there may be a better way of handling this:
On removeAll() you can set a flag like removeEventListenersPending = true, copy the old elements to a temporary new array and run through the it in smaller sized increments (removing event listeners from say 40 objects every enterframe using something like calllater). In the meanwhile if a property change event is fired, you can see if the flag is set and if so make sure the item is in the current source array and not the temp array. When all objects in the temp have had their event listeners removed, set the removeEventListenersPending = false. I think the current implementation may be causing a lot of performace issues since a lot of people may be using ArrayCollections for large data sets (thats what Flex is great for :) ) and may not know of the penalty of the removeAll(). thanks -arpit On 2/15/08, Alex Harui <[EMAIL PROTECTED]> wrote: > Because of the way GC works, I still think it is best for us to remove > the listeners. GC is only on allocation so again, if someone had a handle > to an object that got removed and twiddled a value, the notification code > would run needlessly until GC kicked in. > > > > However, I think you've come up with a great optimization for folks who > know they are destroying everything all at once. > > > ------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Arpit Mathur > *Sent:* Thursday, February 14, 2008 9:39 PM > *To:* [email protected] > *Subject:* Re: [flexcoders] Performance difference between > ArrayCollection.removeAll() and ArrayCollection.source = [] > > > > Hmm, maybe I am missing something here? The only place I see > addEventListener being called is > > > > protected function startTrackUpdates(item:Object):void > { > if (item && (item is IEventDispatcher)) > { > IEventDispatcher(item).addEventListener( > PropertyChangeEvent.PROPERTY_CHANGE, > itemUpdateHandler, false, 0, > true); > } > } > > > > which has the weak-keys boolean flag turned on. Shouldnt that allow > garbage collection to run without explicitly calling removeEventListener ? > > > > On Thu, Feb 14, 2008 at 11:54 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > > Our code has to look like that otherwise if someone kept a reference to > one of the objects that got removed, it would keep the ArrayList from being > GC'd. We added listeners, so we should remove them. If the data objects > are going away too, then you can probably reset the source, but if you see a > memory leak later, I'd definitely check in that area. > > > ------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Arpit Mathur > *Sent:* Thursday, February 14, 2008 8:27 PM > *To:* [email protected] > *Subject:* [flexcoders] Performance difference between > ArrayCollection.removeAll() and ArrayCollection.source = [] > > > > I was trying to debug an issue with the LogBook application we released a > couple of days back. If you take a look at the interface on the main page at > http://cimlogbook.googlecode.com (or if you have installed the > application), you will see a clear logs button. Clicking on that clears an > ArrayCollection that holds a series of LogObjects by calling a removeAll() > function. However we got a bug saying the application would almost hang if > it tried to clear a lot of messages. A quick patch was to reset the source > like so: arrayCollection.source = [] . The performance became lightning > fast. > > Looking deeper into the removeAll function and following the hierarchy to > the ArrayList class, I see that the removeAll loops through the entire > array, looking at each member to see if its an event dispatcher and if so > calling a function to remove the propertyChange listener. > Why is this implemented this way ? Is there any reason I shouldnt just use > source = [] to reset the array ? > > Thanks > > > -- > Arpit Mathur > Lead Software Engineer, > Comcast Interactive Media > --------------------------------------- > post your flex tips on > http://flextips.corank.com > > > > > -- > Arpit Mathur > Lead Software Engineer, > Comcast Interactive Media > --------------------------------------- > post your flex tips on > http://flextips.corank.com > > > -- Arpit Mathur Lead Software Engineer, Comcast Interactive Media --------------------------------------- post your flex tips on http://flextips.corank.com
