Hm, not so impressive. Let’s look at the code again. Oh, yes. I have forgotten about set fixed = true. Not is should be better. Let’s see.

Array get properties: 2334msVector get properties: 2241ms (~96%).

Result is insignificant unfortunately. This is not so huge impact that I expect.

Les’s try another, most common example, when we must to process some value from array/vector and call several times to this value. To prevent constant accessing by index probably we use some temporary variable.

Current test loops:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

var_s:DisplayObject;

__time=getTimer();

for(i=0;i<loops;i++){

for(j=0;j<inputSize;j++)

{

_s=inputArray[j]asDisplayObject;

}

}

trace("Array get properties: ",getTimer()-__time);

inputVector.fixed=true;

__time=getTimer();

for(i=0;i<loops;i++){

for(j=0;j<inputSize;j++)

{

_s=inputVector[j];

}

}

trace("Vector get properties: ",getTimer()-__time);

And results:

Array get properties: 1138msVector get properties: 913ms (~80%)

That is nice. But new question occurs now. If in most cases we storage local value why not use for each ? And in deed this loop consume 7% less CPU that for with local storage, but we lost index. Now everything is clear, we should use for each with fixed vectors to achieve best performance.

NOPE.

Flash Player is even smarter that I thought. Last example:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

inputVector.fixed=true;

__time=getTimer();

for(i=0;i<loops;i++){

for(j=0;j<inputSize;j++)

{

inputVector[j].hasEventListener("");

inputVector[j].hasEventListener("");

inputVector[j].hasEventListener("");

inputVector[j].hasEventListener("");

}

}

trace("Vector get properties: ",getTimer()-__time);

__time=getTimer();

for(i=0;i<loops;i++){

foreach(_s ininputVector){

_s.hasEventListener("");

_s.hasEventListener("");

_s.hasEventListener("");

_s.hasEventListener("");

}

}

trace("Vector get properties, foreach: ",getTimer()-__time);

And results:

Vector get properties: 5937ms Vector get properties, foreach: 6063ms

Conclusion?

AVM is quite well optimized to work on indexes of tables/vectors and each next call to this index has no impact (impact is, but small) to the performance.

Local storage current element looks better, but is slower because of cost of allocation new variable.