Repeater performance and recycleChildren
November 7th, 2008
So one of my bug reports this week was that Lite took an insanely long time to populate the list of playlists when you clicked the “Add to Playlist” button on a song’s info panel. We’re talking like, click the button, lightbox opens, 4-5 seconds later your playlists appear. This was happening even for accounts with a small number of playlists.
At first I thought it must be something with the service call to the backend to fetch the list of playlists, but it was returning long before the list rendered.
So then I thought perhaps it was the class I wrote for paging lists of stuff from the backend, but no, parsing the data wasn’t taking that long either.
So I went to make sure I hadn’t done anything silly in the view, like, manually removed and replaced all the children in the box every time the list changed instead of just using a Repeater. But no, I was using a Repeater. Jay says, “What’s this recycleChildren property on the Repeater class?”
I said, “That shouldn’t matter, this is the first time that Repeater’s been rendered. There’s no children created yet *to* recycle. But I guess I’ll set it true anyway.”
And sure enough, now it renders in more like 1 second, as opposed to 4-5. I understand how recycleChildren increases performance when the data in the dataProvider changes. I think it’s silly that it defaults to false – I’d think that most common uses of the Repeater class would benefit from defaulting to true, and if you have a case where you need it false, then you can specify. But I still don’t understand how it’s faster when it’s the first time it’s created any children at all.
So if your Repeaters are slow – set recycleChildren to true!
And if anyone can give some insight into how it’s faster even on the initial creation of the component, let me know. I’m curious.
And for you Grooveshark Lite fans – that change is live, so if you were frustrated by long lag times on the “Add to Playlist” lightbox, the “Share” lightbox, or on opening a playlist or song info panel, it should be much better now.
March 19th, 2009 at 7:31 pm
Thanks man! I’ve been looking around for ways to optimize my app (I’ve got one here with a ton of data on screen), and I’ll give this a shot.
July 31st, 2009 at 4:30 am
From Adobe:
The recycleChildren property is a Boolean value that, when set to true, binds new data items into existing Repeater children, incrementally creates children if there are more data items, and destroys extra children that are no longer required.
The default value of the recycleChildren property is false to ensure that you do not leave stale state information in a repeated instance. For example, suppose you use a Repeater object to display photo images and each Image control has an associated NumericStepper control for how many prints you want to order. Some of the state information, such as the image, comes from the dataProvider property. Other state information, such as the print count, is set by user interaction. If you set the recycleChildren property to true and page through the photos by incrementing the Repeater object’s startingIndex value, the Image controls bind to the new images, but the NumericStepper control maintains the old information. Use recycleChildren=”false” only if it is too cumbersome to reset the state information manually, or if you are confident that modifying your dataProvider property should not trigger a recreation of the Repeater object’s children.
Keep in mind that the recycleChildren property has no effect on a Repeater object’s speed when the Repeater object loads the first time. The recycleChildren property improves performance only for subsequent changes to the Repeater control’s data provider. If you know that your Repeater object creates children only once, you do not have to use the recycleChildren property or worry about the stale state situation.