For loop.

[lukasyno]

Hello.

"pixi.js has a heavy focus on speed"

for example :

 

for (var i=0; i < this.interactiveItems.length; i++) {

 this.interactiveItems.interactiveChildren = false;

}

example from PIXI.InteractionManager.prototype.update.

 

it is so slower, because in every time "test expression" is calculated..

proof

 

for (var i = 0; i < getN(); ++i)        {                    }                function getN()        {            console.log("calculate N");            return 5;        }

 

this version

 

 

for (var i=this.interactiveItems.length-1; i >= 0 ; --i) {this.interactiveItems[i].interactiveChildren = false;}

 

or this versin

 

const n = this.interactiveItems.length;for (var i=0; i < n; i++) { this.interactiveItems[i].interactiveChildren = false;}

 

is faster.

[Ezelia]

didn't get what you are trying to say  ... this.interactiveItems.length is not evaluated it's not like calling your getN() function 

 

here is a small jsperf test showing that in best case the two aproaches performs equally, but in some cases the first aproach is faster  http://jsperf.com/array-length-vs-const

[Schoening]

In this magical age, if you get REALLY worried about loops that could potentially block your game.

Use a Webworker!

 

http://www.html5rocks.com/en/tutorials/workers/basics/

[lukasyno]

Chrome (v8) use JIT and optimizes this, but firefox not.

I Think PIXI should use length stored in const because it is low level graphics engine and should be as fast possible.

[Ezelia]

@Schoening it's not about blocking loops

 

@lukasyno const is actually slower or equal so why using it ?

[xerver]

`.length` is a property not a function, it is not evaluated it is just read. There is no difference between you pre-storing it or asking the array for it (unless you are modifying the array in the loop).

[lukasyno]

@lukasyno const is actually slower or equal so why using it ?

 

What do you mean "const"? Contstant or nor calculate length in condition in every time?

If first, ok const is now not supported in each browser but i have habit from c++, sorry.

If second, read variable is more faster than calculate length in every time.

 

see here

http://gamedevjuice.wordpress.com/2008/02/15/seven-tips-about-performance-optimization-in-actionscript-3/

This is fundamental optimization, so I'm very surprised.. 

[lukasyno]

@rolaaba it is NOT true see

 

this.a = [1, 2, 3];        for (var j = 0; j < this.a.length; ++j) {            console.log("LENGTH IS", this.a.length, this.a[j]);            if (j == 0)                eval(this["a"]).push(10);        }        //        LENGTH IS 3 1        LENGTH IS 4 2        LENGTH IS 4 3        LENGTH IS 4 10

 

In every time length is calculated because browser does not know whether length is not change DYNAMIC [eval(this["a"])] when "a" can by dynamic variable etc.

[Ezelia]

@rolaaba it is NOT true see

 

this.a = [1, 2, 3];        for (var j = 0; j < this.a.length; ++j) {            console.log("LENGTH IS", this.a.length, this.a[j]);            if (j == 0)                eval(this["a"]).push(10);        }        //        LENGTH IS 3 1        LENGTH IS 4 2        LENGTH IS 4 3        LENGTH IS 4 10

 

In every time length is calculated because browser does not know whether length is not change DYNAMIC [eval(this["a"])] when "a" can by dynamic variable etc.

 

 

still not true ... when you push the new element to the array, JavaScript will update the length property, and it'll just read it as it was a variable in the next loop, it's a direct access not an evaluation !

 

also the example you gave is from AS3 it don't apply to JS.

 

.length in javascript is different from .length() in other languages or sizeof(arr) in C ...

 

[xerver]

@rolaaba it is NOT true see

 

this.a = [1, 2, 3];        for (var j = 0; j < this.a.length; ++j) {            console.log("LENGTH IS", this.a.length, this.a[j]);            if (j == 0)                eval(this["a"]).push(10);        }        //        LENGTH IS 3 1        LENGTH IS 4 2        LENGTH IS 4 3        LENGTH IS 4 10

 

In every time length is calculated because browser does not know whether length is not change DYNAMIC [eval(this["a"])] when "a" can by dynamic variable etc.

 

Javascript is a dynamic language, there is no difference between any of the following (assuming correct context):

 

this.a.push(6);//ORthis["a"]push(6);//OReval(this["a"]).push(6);//OReval("this['a']").push(6);//OReval("this['a'].push(6)");

Doesn't matter. The `push` function is called which will modify the `length` property of the array. `length` is just a property that is tracked *as the array changes* it is not counted later. Each modification updates the length property, that is just how it works.

 

As proof I created this jsPerf, it creates an array and adds a function to it called `getLen()` which returns a constant value of 20, and I also use the `.length` property and compare the speeds of both. As you can see, getting .length is marginally faster (or at least the same). In fact, each time i run it, it switches off and the other becomes faster. This optimization you suggest is not worth the effort involved. I hope this finally proves to you that there is no calculation done in accessing `.length`, if there was then the `getLen()` call would be way faster.

 

http://jsperf.com/lukasyno-length-test

[lukasyno]

I can't believe..

so in JS

time read object property array.lenght = time read local variable.

so strange...

[Ezelia]

@lukasyno : why should they be different ? it's like reading the same object from two different pointers in C language

[PaulR]

Not having used pixi.js I would take a heavy focus to speed to mean they have spent a reasonable amount of time profiling an optimizing their code. 

 

I imagine they would respond to any bottleneck you can identity in their code.

 

I started to learn JavaScript and later CoffeeScript after a long time doing fairly optimized C/C++ code. It takes a slightly different mindset but learning it really hammered home the only optimize when you need to and write the simplest code possible, so it is easy to change later. Since then I have found it quite fun to code for browsers.

[Oscar Abraham]

The way properties work in javascript (variables are slightly faster than properties) and the way the length property works (it does have a special getter), should be a little faster to store it in a variable.

 

But only a little, really, I don't think it would be significant or that anyone would actually notice.

[lukasyno]

Hello again.

 

See here

http://oreilly.com/server-administration/excerpts/even-faster-websites/writing-efficient-javascript.html

 

 

The important lesson to take from this information is to always store frequently accessed values in a local variable. Consider the following code:

function process(data){
if (data.count > 0){
for (var i=0; i < data.count; i++){
processData(data.item);
}
}
}

This snippet accesses the value of data.count multiple times. At first glance, it looks like this value is used twice: once in the ifstatement and once in the for loop. In reality, though, data.count is accessed data.count plus 1 times in this function, since the control statement (i < data.count) is executed each time through the loop. The function will run faster if this value is stored in a local variable and then accessed from there:

function process(data){
var count = data.count;
if (count > 0){
for (var i=0; i < count; i++){

processData(data.item);
}
}
}

 

I dont have any question...

[enpu]

Nice one,

I haven't really played much with javascript performance,

but i did run those functions in jsPerf:

 

http://jsperf.com/test5764574

 

Test 1 was 45% slower on Chrome 27

[xerver]

Nice one,

I haven't really played much with javascript performance,

but i did run those functions in jsPerf:

 

http://jsperf.com/test5764574

 

Test 1 was 45% slower on Chrome 27

 

They are both nearly the same in Chrome 27, and exactly the same in Chrome 28. As previously proven, accessing a property incures a *small* penalty; one that is almost never a bottleneck.

 

I ran this benchmark 4 times in Chrome 27, and got the following results

 

1st run - the results were exactly the same speed

2nd run - the second performed 50% faster

3rd run - the first one performed marginally faster

4th run - the results were exactly the same speed

 

This microptimization is unreliable at best, and not worth all the time people are putting into it.

[Ezelia]

plus if you use closure compiler in advanced mode it'll make all code optimisations for you ... just write clean easy to read code and let the optimisations for Google closure compiler

this is how I do things and it work just fine