[Solved] Javascript performance, conditional statement vs assignment operator

Question

When you have a non-refcounting language (which JavaScript isn’t) and doing an assignment (‘=’, resulting in a copy operation) of a big object it can be “slow”. So a check if that copy operation is really necessary can save you a significant amount of time.

But JavaScript is a native refcounting language:

object1 = {a: 1, b: 2};
object2 = object1;         // refcounting copy?
object1.a = 3;             // test by modifying the first object
console.log( object2.a );  // will return 3 => refcounting

=> so all assignment operations (‘=’) are quite cheap.

And, even more, you are working with a native data type (bool, numbers would be the same) that might be even faster or at least as quick as objects.
NOTE: strings are not refcounted in JavaScript, they are an exception in this case.

So, right now we have learned that the assignment is cheap. But what about the identity check (the ‘===’)?

In your code you must wind your way down through the object this -> crm -> update – this takes some additional time. And then the identicality of the type (bool) must be checked and then if the content (false) is the same.
All of this are adding conditions in the program flow where modern CPUs with their long pipelines might guess the branch wrongly creating a stall and a reload of the full pipeline. This also wastes quite a lot of CPU cycles (although the modern CPUs are quite good at this now).

=> This comparison (‘===’) is quite expensive.

Conclusion #1:
You shouldn’t protect a cheap code by an expensive test that can be easily avoided.
When the code gets more expensive a point will come where the test will save time at the end. This leads to:

Conclusion #2:
Premature optimisation is evil! It can make code harder to read, introduce new bugs, makes code bigger (also bad for cache efficiency), …
=> Only optimize those parts of the code where you are sure you are running in a performance problem – and then only based on profiling informations. Humans are quite bad at guessing the effects here…

Accepted Answer

When you have a non-refcounting language (which JavaScript isn’t) and doing an assignment (‘=’, resulting in a copy operation) of a big object it can be “slow”. So a check if that copy operation is really necessary can save you a significant amount of time.

But JavaScript is a native refcounting language:

object1 = {a: 1, b: 2};
object2 = object1;         // refcounting copy?
object1.a = 3;             // test by modifying the first object
console.log( object2.a );  // will return 3 => refcounting

=> so all assignment operations (‘=’) are quite cheap.

And, even more, you are working with a native data type (bool, numbers would be the same) that might be even faster or at least as quick as objects.
NOTE: strings are not refcounted in JavaScript, they are an exception in this case.

So, right now we have learned that the assignment is cheap. But what about the identity check (the ‘===’)?

In your code you must wind your way down through the object this -> crm -> update – this takes some additional time. And then the identicality of the type (bool) must be checked and then if the content (false) is the same.
All of this are adding conditions in the program flow where modern CPUs with their long pipelines might guess the branch wrongly creating a stall and a reload of the full pipeline. This also wastes quite a lot of CPU cycles (although the modern CPUs are quite good at this now).

=> This comparison (‘===’) is quite expensive.

Conclusion #1:
You shouldn’t protect a cheap code by an expensive test that can be easily avoided.
When the code gets more expensive a point will come where the test will save time at the end. This leads to:

Conclusion #2:
Premature optimisation is evil! It can make code harder to read, introduce new bugs, makes code bigger (also bad for cache efficiency), …
=> Only optimize those parts of the code where you are sure you are running in a performance problem – and then only based on profiling informations. Humans are quite bad at guessing the effects here…