The issue is that in many languages (such as C++ or Java), (j+15)/7 *is* an integer operation when j is an int. So for those of us who come from those languages (and who see the strong typing in AS3 as a move toward those languages), this is confusing.

Even if you argue that having this be a floating point operation is ‘better’ than having it be an integer operation, a modern compiler should be able to analyze the code to discover that the result of this operation is stored in an int and do an integer version of the division operation.

If I remember correctly, the player team investigated this approach, and found that it was difficult to get strictly correct behavior in edge cases (like dividing by NaN, etc). As a trade-off, they did an intrinsic conversion to Number in many cases that aren’t strictly necessary.

They may have improved this in more recent version of the VM. I haven’t worked at Adobe for 2 years, so I don’t really know what’s going on these days.

Your blanket statement that Number is better than int is not fair at all.

Your loop is doing an int() cast every single iteration. Of course this is going to be slow. Note the difference if you don’t divide by 7 and it doesn’t have to do a conversion.

var now:int = getTimer();
var j:int;
var i:int = 10000000;
while (i–)
{
j = (j + 15);
}
trace(getTimer() – now);

41ms

If you divide by 7

154ms

Obviously, doing floating point math using Number is faster than doing it with int. But doing integer math with int is MUCH faster than doing it with Number.

If you’re using floats, use Number. If you’re using integers, use int.

Thanks for engaging in this discusssion!

Not sure what the timings are these days with player 10, but (a) you’re right in the narrow sense, and (b) I still think there is an efficiency issue in the broader sense.

Jacob’s point (and drawtree’s, implicitly) is that certain operations are faster when done as ints. That is undoubtedly true.

However, for those of us who come from a non-dynamic language background (C / C++ / Java), the expectation is that built-in integral types are there precisely for the purposes of being faster than generic number types, even when doing things like printing them or dividing them.

In many other languages, dividing two integers compiles down to an integer division operation which is much much faster than a floating point integer division operation. In ActionScript (as of player 9, anyway), the integers are converted to number before the division. And as for the print statement specified in Gary’s excellent talk, it’s a mystery to me why the conversion occurs. Perhaps because the signature of the print method takes an untyped argument?

So… to summarize… I believe that the performance behavior of ints in ActionScript would be surprising to many people. Dividing two ints would normally be faster than dividing two floating point numbers, for example.

As for the title of the post, I may have been guilty of engaging in hyperbole. Maybe it should have been called “consider using Number instead of int inside of tight loops”. I certainly continue to use ints on a daily basis for typechecking purposes.

Refer 25p. of this document:
http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf

If you understand concept of explicit-type-casting you’re already know what I want to say.

Once you start using calculations that add decimal places to the int(like division/multiplication or adding non integer numbers) then you get a slowdown since the result basically has to be rounded. This explains your results above.

Even so, the conversion is pretty fast. Change m = ((m + 15) / 7) to m = Math.round((m + 15) / 7) to simulate int rounding and you’ll see using an int seems faster than using Math.round() on a number.