Here we can see that a doesn't escape this block, and no operation here can affect a.length, so we can just substitute 3 for a.length.
We also don't need to do this when starting -- we can delay analysis until we determine that the function is sufficiently expensive to be worth optimizing.
Which means that this doesn't need to slow down start up time.
Which isn't to say that your javascript implementation does this, but it isn't particularly hard.
What you need to do, rather than speculate, is to profile.
Fortunately some nice people have done this for us already.
Well length is stored as a special field on object instead of key/value pair, it is kind of shortcut property. Analyzing escaping etc, all require some logic.
Profiler is not an ideal, writing better code is never harmful, it is good practice. We usually have millions of lines of code and you can't sit and profile thousands of different patterns unless you are paid millions of dollars for applications.
Length may be stored as a special field on some implementations, but it isn't required to be the case -- be careful not to confuse your favorite implementation with the language itself.
The problem with 'writing better code' is that what is better depends on many variables.
A profiler is a way to test what is better, and how much better, in a particular environment and with a particular workload.
This allows you to make decisions based on actual data rather than guessing -- it's often the case that the optimizations you think ought to matter just aren't important at all for how the code performs.
In the absence of profiling, I'll always recommend maximizing readability, since that's the most constant cost.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Actually, it's pretty easy to do escape analysis and determine that a property can't change within a given region.
Here we can see that a doesn't escape this block, and no operation here can affect a.length, so we can just substitute 3 for a.length.
We also don't need to do this when starting -- we can delay analysis until we determine that the function is sufficiently expensive to be worth optimizing.
Which means that this doesn't need to slow down start up time.
Which isn't to say that your javascript implementation does this, but it isn't particularly hard.
What you need to do, rather than speculate, is to profile.
Fortunately some nice people have done this for us already.
stackoverflow.com/questions/959224...
So it seems that some implementations do make a.length almost as efficient as using a local variable, at least in some circumstances.
The take away message here is that you need to use a profiler to understand performance.
Well
lengthis stored as a special field on object instead of key/value pair, it is kind of shortcut property. Analyzing escaping etc, all require some logic.Profiler is not an ideal, writing better code is never harmful, it is good practice. We usually have millions of lines of code and you can't sit and profile thousands of different patterns unless you are paid millions of dollars for applications.
Length may be stored as a special field on some implementations, but it isn't required to be the case -- be careful not to confuse your favorite implementation with the language itself.
The problem with 'writing better code' is that what is better depends on many variables.
A profiler is a way to test what is better, and how much better, in a particular environment and with a particular workload.
This allows you to make decisions based on actual data rather than guessing -- it's often the case that the optimizations you think ought to matter just aren't important at all for how the code performs.
In the absence of profiling, I'll always recommend maximizing readability, since that's the most constant cost.