3 ms·

> Sure you can't know which bits of a program are going to be slow without measuring, but that doesn't mean you have no clue at all. You can often make a very g

> Sure you can't know which bits of a program are going to be slow without measuring, but that doesn't mean you have no clue at all. You can often make a very good guess! You can make a good guess! Just, measure it to be sure before you start optimizing.

IshKebab 3y ago
No, that's my point! Measuring is good, but some things are obviously slower. For example preallocating arrays. You don't need a benchmark to tell you it will be faster because it literally can't not be. Another example from my recent real life: I changed a data structure from a hashmap to an array with integer keys. I didn't profile it because can't not be faster. And I knew it needed to be fast because it is called for every branch in my program.
- shadowgovt 3y ago
  > 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. https://dev.to/henryjw/populating-a-pre-allocated-array-slower-than-a-pushing-to-a-regular-array-4l43 https://dev.to/henryjw/populating-a-pre-allocated-array-slow...
  - IshKebab 3y ago
    I was talking about C, C++, Rust, Zig, etc.

IshKebab 3y ago

No, that's my point! Measuring is good, but some things are obviously slower. For example preallocating arrays. You don't need a benchmark to tell you it will be faster because it literally can't not be. Another example from my recent real life: I changed a data structure from a hashmap to an array with integer keys. I didn't profile it because can't not be faster. And I knew it needed to be fast because it is called for every branch in my program.

shadowgovt 3y ago
> 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. https://dev.to/henryjw/populating-a-pre-allocated-array-slower-than-a-pushing-to-a-regular-array-4l43 https://dev.to/henryjw/populating-a-pre-allocated-array-slow...
- IshKebab 3y ago
  I was talking about C, C++, Rust, Zig, etc.