4 ms·
> because just iterating over all the pixels in an image by using "for(let i=0;i< pixel.length;i++){}" is 3x slower than using var, causing just a single full l
by the8472 10y ago
> because just iterating over all the pixels in an image by using "for(let i=0;i< pixel.length;i++){}" is 3x slower than using var, causing just a single full loop to be 80-120ms on a good computer.
That is an implementation detail. Of specific chrome versions.
That does not make let itself bad practice. In principle it should be significantly easier to optimize for a compiler because its more limited scope. So in the long run or possibly on other browsers it is likely best practice.
Putting transients before long-term behavior leads to urban programming myths and legacy baggage.
In fact in some jsperf benchmarks on chromium let happens to be faster for me.
- devwastaken 10y ago>Putting transients before long-term behavior leads to urban programming myths and legacy baggage. Not when the problems still exist. When they stop existing, sure, but the statement generally goes along with how some parts of ES6 are not well optimized yet. Over time, they should be optimized, but I cannot design something for an event that hasn't happened yet and cannot be tested.
- lederhosen 10y agoYou are doing it wrong. let is better than var (in every way), so you should never ever use var. Of course you can design for the future. Designing for the future is using let and transpile to a dialect that is used by most browsers today.
- devwastaken 10y ago>let is better than var (in every way), so you should never ever use var. Not in the case I presented. let has benefits, but that does not mean its 'better in every way'. Again, dogmatism. Granted, the case I give is many, many iterations, it still is a problem if you're doing image filtering.