object pools

[eigenface]

Have you thought about using object pools for tween/timeline instances? As you know, in addition to function calls, object creation is slow in actionscript. More importantly, the frame rate can stutter when the garbage collector runs. I believe your platform currently deletes references to unneeded instances and leaves them for the garbage collector. Maybe it would be better to keep them in a pool, wipe their state, and reuse them later.

 

There could be a default pool size which the user could change, populated when the class-level init happens, or maybe not populated at all unless the user calls an initPool(size:uint) method. Tween/timeline instances would be drawn from the pool when methods like TweenLite.to are called. Calling new TweenLite would still create a new instance, of course - TweenLite.to would also if the pool is empty. Not sure if object pools are necessary for you platform, just something to think about.

 

Also, I wonder how difficult it would be for me to implement a separate object pool utility for tweens/timelines. It could potentially get complicated because of the references between tweens and timelines. I guess I'd want to keep a stopped timeline full of pool tweens, which I'd reparent and reinitialize when I needed them.

[GreenSock]

Yep, I have thought about this (object pools seem to have gotten some hype recently) but there are some significant down sides to using them:

 

1) It takes time to decomission and recommission objects (wipe their properties, etc.). Often this is actually more expensive than just creating new instances.

 

2) It requires that you know WHEN to decommission an instance, but this kills some of the flexibility of the platform. Let's say you create a tween and store it as a class property so you can restart it later or something. Maybe that tween runs and then finishes, but 10 seconds later, you want to restart it - if that instance got recycled, it may now be populated with a completely different tween! That'd be a huge problem So there's no way of knowing for sure if the user hung on to an instance for later use. To do object pools, I'd have to require the user to set a property that specifically tells me their intent (and trust me, plenty of people would forget to even do that and I'd get lots of e-mails saying "my tween is broken! What's wrong with your stupid engine? It's filled with bugs."

 

3) File size. It takes more code to manage the object pools, and I'm trying to keep things as lean as possible.

 

I have run speed comparisons with object pools in TweenLite and it actually performed slightly worse. And some other engines use object pools and they're generally slower than TweenLite/Max. I even tested turning that feature off in other engines and saw that there was no performance benefit.

 

I tested the startup latency in TweenLite compared to other engines using Moses Gunesh's TweenBencher tool and the latest TweenLite blew the doors off all of 'em including GoASAP-based ones. So the object creation really isn't as horribly slow as you might have been lead to believe.

 

Thanks for the suggestion, though I've put a ton of time into optimizing the snot out of this platform while keeping it robust and flexible. http://blog.greensock.com/tweening-speed-test/

[eigenface]

Ok, I guess you're on top of it then. Pre-pool-hype, I had done my own tests and noticed object creation is slow, so I try to reuse instances where possible. This is probably more of a concern when the object creates other objects in its constructor (and so on), which happens a lot for library items designed in the GUI - all the children (and grandchildren, etc) have to be created.

[GreenSock]

Right. Exactly. And from what I understand, code inside the constructor is not optimized (not sure why), so it runs slower than code in any other function. So if you've got a whole bunch of stuff going on in your constructor, that'd explain the performance hit.

[eigenface]

Does it help if I call an init function in the constructor and put all the constructor code in init instead?

[GreenSock]

Well, the answer is "maybe". It depends how much code you've got in there. Function calls are expensive, so if you're calling init() from inside the constructor, there's a cost right there. Sometimes it's faster to just leave it in the constructor. But if there's a lot of code in there, yeah, just put it in a separate init() method.

[eigenface]

Thanks, that makes sense.