> For example preallocating arrays. You don't need a benchmark to tell you it will be faster because it literally can't not be.
This assertion is false for JavaScript arrays in the v8 engine in some contexts. Preallocation of a JS array causes the engine to make a heterogeneous array, which is more expensive because it's an object under-the-hood. Allocating the array using repeated `push` calls of homogeneous data lets the engine know it's a homogeneous-type array, which is an "exotic object" that can use more optimal representations under-the-hood. (Faster than both is preallocating a homogeneous array, although that of course requires us to know what kind to preallocate).
This is another example of where premature optimization can lead a developer astray. Abstractions are far too complicated these days, and it's too easy to guess wrong without hard data.
This assertion is false for JavaScript arrays in the v8 engine in some contexts. Preallocation of a JS array causes the engine to make a heterogeneous array, which is more expensive because it's an object under-the-hood. Allocating the array using repeated `push` calls of homogeneous data lets the engine know it's a homogeneous-type array, which is an "exotic object" that can use more optimal representations under-the-hood. (Faster than both is preallocating a homogeneous array, although that of course requires us to know what kind to preallocate).
This is another example of where premature optimization can lead a developer astray. Abstractions are far too complicated these days, and it's too easy to guess wrong without hard data.
https://dev.to/henryjw/populating-a-pre-allocated-array-slow...