Type casting

[UnknownGuy]

Hey everybody,

I'm a new to AS3, been liking it a lot though, makes so much sense. :)

From what I understand, type casting is now matters during run time, not just a precaution during compilation. (And thus I think there is a speed increase).

1.Is it possible to type cast a whole array?

2. If you create an object using {propName:value}, is it possible to typeCast that?

Thanks!

[senocular]

1. Not in Flash, but you can in Flex using the ArrayElementType meta data tag
http://livedocs.macromedia.com/flex/2/docs/00001652.html

2. Not really, but kind of. You can't type those values, but in creating those values, they will be typed by Flash for runtime manipulation, i.e. you can use typeof and is to get type information from those values. This essentially means no compile-time type checks. Errors resulting from runtime conflicts will still occur, though. Ideally you would create a new class to facilitate (and type) those properties.

[UnknownGuy]

Well, this is a real speed issue so I'm shying away from making a class for it. (Which I assume is slower.)

There are about 1100 of these objects, and the FPS is already struggling. :p

That's not why, but there's lots of other stuff going on. :p

[joa__]

It makes sense to type-cast your array objects and objects properties. But please do not use an object to hold some data. It is faster creating a class like Point with the x,y properties instead of using an object like {x:0,y:0}.

Typecasting a whole array is only a compiler hint but it does not give you any speed efforts afaik.

You may want to read theese articles:
- http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf
- http://blog.andre-michelle.com/2005/as3-optimations-suggestions/

[UnknownGuy]

Thanks for the links joa__, really interesting and good to know.

I did a comparison between the two you suggested, and for initialization only(though from the links, apparently accesing is much faster for classes), point ran about 5% faster.

One thing I don't understand, on page 43 of the pdf, why don't they use JIT for class initialization? Does that mean I should just have initialization call another function with the real meat of the code?

Or when I create a new instance, have that routine call a create function?

Thanks!

[joa__]

This is a point where very detailed in-depth knowledge is required and I can only mix together what I have read so far.

They say that there is a "hotspot-like" decision. Don't ask me where the difference between hotspot and hotspot-like is. If it is no real hotspot you can not be sure that every piece of code will be speeded up.

I think the idea of a routine calling the constructor (which means: creating an instance using new Class) would not be a good idea since the constructor has to be called anyway.

If I get the paper right at this point you should just not put the performance intensive code into the constructor. This definitly has to be tested and I will do this on saturday or sunday. This means comparing a performance intensive constructor versus a constructor calling some function which holds the code.

[UnknownGuy]

Sorry, I should have explained myself better.

When I said have that routine call a create function or have the class constructuor just call another function I was comparing:

instance=new theClass()
instance.create()

//TO

//Below is just the imaginary constructor
function theClass(){
create()
}
instance=new Class()



I will be interested in the results!

[joa__]

Very funny results today. This was the code to create the class and get the average time.


for ( var j: int = 0; j < 10; j++ )
{
t0 = getTimer();

for ( i = 0; i < 10000; i++ )
t = new Test();

t1 = getTimer();

result += ( t1 - t0 );
}

result /= 10;


Now the funny part. I thought about a "cpu intensive code" like the paper said. This was my "cpu intensive code".


//-- BEGIN cpu intensive code
var x: Number;
for ( var i: int; i < 5000; i++ )
x = Math.sin( i );

var y: Number;
for ( var i: int; i < 5000; i++ )
y = Math.cos( i );

//-- we want ugly code, so dont use stringbuilder
var s: String = '';
for ( var i: int; i < 5000; i++ )
s += String.fromCharCode( Math.round( Math.random() * 0x80 ) + 0x80 );
//-- END cpu intensive code


Then I tested two cases. The first was the code in the constructor and the second the code in an init function.

Case #1:

package
{
final public class Test
{
public function Test()
{
//CODE GOES HERE
}
}
}


Case #2:

package
{
final public class Test
{
public function Test()
{
init();
}

private function init(): void
{
//CODE GOES HERE
}
}
}


I posted this for you to understand exactly how and what I have tested. If you can find any mistake here I would be glad to hear about it. But now the results:

Both cases resulted in the same speed. No difference here. This made me think about the paper and I thought like "why do they write this if both methods result in the same speed?". If we follow the paper then it says that the JIT will not be used for the code inside the constructor. The JIT is also based on the "hotspot-like decision". So I took a closer look at the "CPU intensive code"(tm) and now imagine you have to make a decision and you are the JIT. Does this code looks like a beauty? No. It does not look like code some JIT would execute based on some "hotspot-like decision"(tm).

Same tests with a different code to make the CPU suffer.


//-- BEGIN cpu intensive code
var j: int = 0;
for ( var i: int = 0; i < 1000; i++ )
j++;

for ( var i: int = 0; i < 1000; i++ )
j++;

for ( var i: int = 0; i < 1000; i++ )
j++;
//-- END cpu intensive code


Now this looks like a present to the AVM2. And what about the results? Case #1 (with the code in the constructor) was noticeable slower. There was a difference of approx. 30ms in my tests. Just as the paper says: Do not put expensive code into the constructor. But it makes no difference at all if your code is not optimized by the JIT :)

[cancerinform]

Have you tested when you leave the constructor empty and call the function init with the the instance name t?

I don't see much difference when you either do something in the constructor itself or call a function from the constructor, which does the same.

[joa__]

Code inside the constructor will not be speeded up by the JIT.

[UnknownGuy]

I sortive understand what you mean joa__, but not completely.

If I understand correctly, in the first test the optimization isn't done whether or not it is in the constructor, so it doesn't matter.

But in the second, if its not in the constructor, its runs faster because it is optimized?

And when you say code inside the constructor is not sped up by the JIT, that means if it is not in a function correct?

Thanks!

[joa__]

The first test leads to the same results because the code is executed at the same speed. Since we do not know what is going on behind the scenes I can only assume that the code is not speeded up by the JIT.

The second test gives us a different result. Code inside the constructor runs slower than inside a function. This is exactly what Adobe's paper says. I just wanted to test this because it sounds a little bit strange.

[UnknownGuy]

Ok, thanks!

(I still don't know why adobe doesn't do JIT for the constructor though(or check to do JIT), doesn't make sense to me :p ).