Skip to main content
V
viatropos
Known Participant
October 29, 2009
Question

Spark DataGroup Object Pooling

  • October 29, 2009
  • 2 replies
  • 1572 views

Hey,

I've created a Tree component extending the Spark List, and it was so easy!  Love the SkinPart architecture.

Now I'm facing a big performance issue.

Every time I open a branch of the tree, the DataGroup has to create the item renderer from scratch, even though I have "useVirtualLayout = true".

This is because "useVirtualLayout" only works if:

a) All of the item renderers are the same (ie. there is no itemRendererFunction)

b) if there are more items than there is visible space.

My tree a) has multiple types of renderers, and b) has more than enough space to fit everything, so I get none of the benefits of the built in renderer caching....

I would like to cache the renderers even if there is excess visible space (so if I open the root node, and it creates 3 child nodes, and there is room for 20 child nodes, and then I close it, it still saves those created child nodes in the "freeRenderers" cache so the next time I open it, it can just "pop()" them from the stack).

In addition, I would like to be able to cache node renderers that are of different types.

To accomplish this, I would need a more robust Object Pool solution than the built in DataGroup "freeRenderers" solution.  I'm wondering, would adobe like to create such a system?  If you could define something like a "cachePolicy" on the DataGroup, where "cachePolicy = new CachePolicy()", and the CachePolicy class defines an array of CacheItems like:

- CacheItem

-- class factory name

-- cache number (how many to store)

Then it would be very easy to customize how the DataGroup could cache renderers.

Then by default, it would do what it does now.  If you customized it with your own CachePolicy object, you'd have to manually clear it and whatnot, which wouldn't be a hassle at all.

Any ideas or better solutions on this front?

Thanks,

Lance

This topic has been closed for replies.

2 replies

A
Anonymous
October 30, 2009

Lance -- great to hear your enjoying the architecture, and REALLY

excited to hear you're tackling a tree component.

At this point in the schedule, I don't think you're going to see

significant changes to the itemRenderer pooling policy. Some minor

refactoring of the APIs might be possible though. So if you wanted to

take a crack at what those APIs would need to look like to make it

easy to extend DataGroup and easily modify the pooling algorithm, that

might be something that could slip in (no promises though).

Have you tried that yet?

Ely.

V
viatroposAuthor
Known Participant
November 3, 2009

Hey,

I've actually come up with something I really like, much more modular.

I've created an ObjectPoolManager (a fun name that makes sense), that works just like the other flex managers (Manager + ManagerImpl, singletons).

That has basic methods: checkIn, checkOut, add, and remove, and checkOutFactory.

- Add: creates an ObjectPool of name "name" and allows you to add objects (renderers in this case) to that pool.

- Remove: removes the ObjectPool, and all the cached objects it contains.

- CheckIn: adds back an object to the pool

- CheckOut: removes an object from the pool.

- CheckOutFactory: gives back an IFactory with an ObjectPool inside, so you can use object pooling with IFactory.

This way, I can do this:

protected function cache(object:*):void

{

     if (object is ITreeItemRenderer)

          ObjectPoolManager.checkIn(object, "treeItemRenderer");

}

public function treeItemRendererFunction(item:Object):IFactory

{

     return ObjectPoolManager.checkOutFactory("treeItemRenderer");

}

<test:Tree id="tree" width="80%" height="80%"

rendererRemove="{cache(event.renderer)}" removed="{cache(event.target)}"

rendererAdd="event.renderer.visible = true"

itemRendererFunction="treeItemRendererFunction"/>

You can also specify the size of the pool, and whether or not it can grow.  It makes it super modular and so I don't have to change anything with the DataGroup, and I could use it in other things like the old mx:List and even Group.

With that my tree has 10 different node renderers, all very rich and complex, and scrolling is pretty smooth, even with 30+ 100height skinnable renderers.  Without it, it almost crashes.

A
Anonymous
November 3, 2009

Having a central Pool Manager is an interesting idea, but I'm a little

concerned at the potential leaks it might create. Without a finalize

method, it's hard for actionscript objects that 'own' a pool to clean

up the pool when going away, no?

E.

matt_chotin
matt_chotin
Inspiring
October 29, 2009

Seems pretty reasonable. We didn't go this far in the first release

to keep things simple for now with the thinking that we'd improve upon

it later.

Matt

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices