[caymanjim]

Agreed. Hardware is almost always cheaper than engineering time, until it isn't, and that's when you should spend the time on targeted optimizations.

[preg_match]

Typically this is backwards: simpler solutions often are more optimal, and complex solutions are not. Most code is slow because it’s just poorly written. If you write it simpler, then you can make it faster and easier to read. This isn’t always true, but it is true for 99% of the low hanging fruit optimization work that’s done in practice.

[cryo32]

Yeah good luck with that attitude over time. Most people don’t hang around in an org long enough to see that assumption scale to renting hardware than costs $900k a node a year.

[falsemyrmidon]

Seeing what you made get to the point that that's an issue is a "a good problem". Yes, it's worth it to optimize at that point, but that's still an argument for what I consider premature optimization.

[facundo_olano]

Most orgs never get to that scale

[gunalx]

The difference can also be from having builds over night to being able to build, test and deploy in a few minutes with just a few optimisations.

[lokar]

And as you approach that point you should have fleet wide profiling (sample based) so it’s clear what’s worth improving.