[Tweener] Tweener 1.33.74

[Zeh Fernando]

Hey Cedric,


> I have got a very naive question: I saw you declare for var loops using var
> i:uint, as far as I understand (and tested), var i:int is faster. Overall I
> don't think this changes anything, except maybe when there are hundreds of
> tweens..., but do you consider such low optimization technique or do you
> think this is purely crap considerations ?


You're right, it is faster. There are, in fact, a lot of small things
slightly wrong (or less-than-optimal) with Tweener. That's one, and other is
that the tween overwrite loop It shouldn't be a loop at all, having a
dictionary list of all objects that are tweened would be much faster.

Low-level optimization techniques like that are not crap. There are moments
they're really important. Of course most of the time it's not like you
should build all your code based on weird rules that won't make sense to
anyone who's reading over your code, so trying to pre-emptively do loops
backwards and never recreate vars and things like that can be a pain in the
neck, but in libraries that have reached a stable point and will be used in
various moments (like a tweening library), it makes sense to try different
techniques to see where can someone squeeze more performance and less memory
usage.

To put into perspective: a while ago I build an experimental tween engine of
my own, to use on my own projects, this time using a better AS3 approach and
many of those small optimization techniques - ints without promotion to
number, reusing variables from a poll instead of creating them, etc. It's
more or less what the Tweener 'elegant' branch was supposed to be, although
it uses a slightly different syntax and it's much more geared towards *my*
development approaches today (i.e, no special properties at all, events
instead of function callbacks) and something I can break/change whenever I
want. I won't go into detail because this is something I built for me and
not something I plan to make public like I did with Tweener (not to mention
some people take this tweening business too seriously), but it suffices to
say the results impressed me both in framerate/performance and memory usage.
Building it 'right' and without unnecessary overhead was what allowed the
engine to be fast, but 'small' optimizations (most of them from Joa Ebert's
material - check it out if you haven't yet) are what made it even better.

The thing with Tweener, the way it is now, is that so many things should be
changed internally (the tween list loop being the biggest one) that it
reaches a point where a major overwrite would make more sense. I started
looking at it a while ago and rewrite it (what I called the "elegant"
branch), but in the end there are so many small things that you begin to
question why just overwrite the code without also rethinking the API. The
'special properties' approach is what bugs me the most today. It's useful
and it's quick, but it's sort of the wrong way to approach that kind of
problem IMO.

This is something I'll go into more detail once I publish the post-mortem
article, but what I've decided to do was just to freeze Tweener code the way
it is and move on. I'll instead be contributing to Firstborn's internal
Tween engine, I'll talk more about that in the future.


Actually my initial goal was to understand overall AS performance, not to
> look down for such in Tweener's code. It is just that I am sticking with
> Tweener because of its simplicity to use and now that I understand
> differences between 'int and uint' + 'array.push and array[array.length]' I
> want more :P
>

Don't worry, you're absolutely right. Although I still use Tweener on a few
projects, I'm of the opinion that much of its internal design tries to
follow a AS2-like approach, so somethings should be dropped, and certain
early optimizations (like using uints) were never re-considered. It works
well, don't get me wrong, but when you start having thousands of tweens,
it's not exactly great.

It's just that there's so much that could be reconsidered that it warrants
an API change too. Since that can't be done with the project at this state,
it's better to move on.


Zeh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.caurinauebi.com/pipermail/tweener-caurinauebi.com/attachments/20090610/050a0b01/attachment.htm>