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.