As for getTimer, the performance impact of a single conversion should be so minor that it won’t affect the test, which includes a loop of one hundred million iterations. Still, point taken. :)

<<

to * is faster and not slower – but I do this on uints, not ints, and do not store the value sumwhere as you do there, but use it right away (I’m aware of the famous debate about uint treated as ints or even numbers thingy…). In all my tests, no matter what version of Flash player and platform used,

>>

,

<<

, and

&

(the fastest of the three) perform faster than the regulars operators.
Refer to http://wonderfl.net/c/bVZM, considering the original from Devon_o – http://wonderfl.net/c/3mIv – and finally leading to something like http://wonderfl.net/c/15wK – unachievable display the ‘standard’ way, thx to mostly bitwise ops and vector bitwise cast calls.

One important thing to mention (seeing you blog ‘n blog on optim) : I often use vector call casting – accelerating the calls inside vectors big, big time (in LUT mode for instance). Use the bitwise

>>0

to do the cast in uint – having a _lookupTable[i] where i is not uint is slower than doing _lookupTable[uint(i)] and is slower (depends on cases but mostly) than

_lookupTable[i>>0]

.

Btw, in your test, you do a *4 – which is a pretty small operation – maybe try *256 or so…

 <<9

! – also,getTimer() renders… an uint. not an int.

My two cents anyway :) Keep it up, good blog!

I would guess that multiplying by a floating-point number would be a good deal slower, but I should do a test to make sure. Perhaps there will be a follow-up article about that. :)

// Division
i * 16; // normal

looks like a multiplication.

Also how does the division compare with (* .25) ?