koobas.hobune.stream
iTween iPhone Performance
I'm looking to use iTween for my iPhone app and wanted to get a sense of how efficient it is? Obviously that's an open-ended question, but give me a ballpark. 2x less efficient than manual Lerping, or 50x?
Also, how much will using iTween affect my app's build size? iTween 2.0 is 270+KB, 5000+ lines of code, which seems excessive, but how much of that will be added to my final build? I'm guessing only a small fraction because a lot of that code has been commented out.
Any advice on this would be great. I don't want to integrate iTween fully into my game only to find out it's slow as hell.
To use your words, it is indeed "slow as hell". The current version that's available in the store (2.0.45) is very inefficient. It's frequently as bad as 300+ ms spikes in what I would consider light to moderate use on latest-gen iOS devices. I'll break it down...
Starting with the interface: it uses Hashtable, which right out of the gate is slow, considering that the data being passed around consists of a large number of value types which results in boxing overhead (Color, Vector2, Vector3, float, int, double, bool, etc). As the Hashtable is passed to iTween there's a several-step data grooming process that results in lots of unnecessary memory churn. Each new tween results in its Hashtable being cloned at least twice just to perform some simple casts and adjust the key case (additional unboxing and re-boxing here).
After data grooming, it instantiates and adds an iTween component to the target game object for that specific tween and then adds the parameters Hashtable for that tween to a static Arraylist that contains all the Hashtables for tweens that exist in the scene. The data has a belongs-to relationship to that component, so there's no reason to store it separately, but either way it's inserted at the beginning of the Arraylist (which is an expensive insert) and then immediately after that it searches through the entire Arraylist of Hashtables doing hash lookups into each one until it finds the one it's looking for. Upon completion, it deletes the associated iTween component.
It's worth noting that this is one component added and deleted per-tween, not per-object. If you want to interpolate color and position, it will be adding two components and then deleting them once it's done. If you're already interpolating position and you call to interpolate a different direction, it will delete the existing component and add a new one. Additionally because of the above way iTween handles data, for every tween that exists (active or paused - even on disabled/inactive game objects), both the creation and completion of tweens becomes more expensive.
During the creation, update, and completion it doesn't cache any component lookups, leading to a bunch of extra processing, and it also doesn't pool any of the iTween components that it's creating and destroying constantly, which quickly adds up to a lot of CPU time and memory churn going on.
The Color adjustment tween types also have a nasty default behavior of repeating that entire process for every child of the target object - including creating a duplicate identical Hashtable for each child recursively and going through the same initial data grooming process for each one on already-groomed data and all the creating, adding, and later destroying of iTween components.
I'm not posting this to bash the product - I'm posting this because I haven't seen this information anywhere else and had it been available months ago it could've saved my team some serious headaches. I sincerely hope it gets optimized, but I'd stay away from it in its current form unless you plan to dig in and do some refactoring. Honestly though, the bulk of code in iTween.cs is just handling the awkward boxing related to the Hashtable interface and the internal management of the tween args Arraylist, which is the problem with iTween in the first place.
In other words, you're honestly better off just starting from scratch.
Thank you for this explanation. Have you built your own tween engine or have used something else ins$$anonymous$$d? (like LeanTween)
We ended up refactoring iTween, since it was already pretty firmly embedded in our project. It took about a week to cut out the excess and get the guts of it to work smoothly once we isolated the problem areas, which was no small task, and then probably around two to three weeks total additional work ongoing as the project continued. I'd happily share the resultant code, but I don't own it so unfortunately I can't. I can say that it involved introducing non-component tween arguments to limit the number of iTween components on each object to no more than one.
Forgot to mention this: Robert Penner's easing functions (which are used in iTween) are available under BSD license here: http://www.robertpenner.com/easing/
From there, all you need is logic to manage your individual tweens, which is really not that big of a task.
iTween is a fantastic piece of work and offers great performance inline with any "manual" method you could devise.
You are free to alter/reduce the code in anyway you see fit as long as you at least leave a line with "props" to the author. So if you only use say the MoveTo function and mebe the Hash table, then you can delete all the other jazz to save a few bytes, but to be honest once you compile the app the size difference of adding the iTween script will be negligible.
It does look fantastic... almost too fantastic... which leaves me thinking, what's the catch!
LOL Tylo. But, nah it's a well written little proggie. It basically does what you would; but puts it all in one nice static Class rather than a plate of spaghetti. It's a good piece o' code. :)
I would not use iTween if you are planning on deploying to the iPhone. iTween can be quite slow and cause framerate drops. I put together a comparison between iTween and LeanTween (another competing tweening engine), where I animated 1,500 boxes. LeanTween zips along at an almost constant 250fps while iTween drops at times down to as low as 2fps.
As far as increasing the package size, LeanTween is highly optimized and only comes to 775 lines of code. I doubt when it's compiled it would add more than maybe 5k of size to your build...
LeanTween can be downloaded from the Asset Store for free.
I have had the same problem. Incredible performance issues on IOS devices when heavily using iTween. It took me 3 days to rewrite all tweens to Prime31's GoKit. And the results are incredible, no more performance spikes, and frequent garbage collections.
