5 ms·

I think you missed the gist? They are saying if you are saying "this piece needs to be more performant" you need to measure that first, before making your choi

by lbotos 8y ago

I think you missed the gist? They are saying if you are saying "this piece needs to be more performant" you need to measure that first, before making your choice of what to make better. You are saying, "you can with an idea in mind optimize before you go and it will have better performance" but the current prevailing business logic is do not optimize until you know it's "the right thing". AKA premature optimization is bad. Did I mis-interpret what you are saying?

ams6110 8y ago
I think GP is saying, if you are at a point in development where you can choose A or B, and A has foreseeable better performance or scalability, all else being equal choose A. A lot of assumptions there and real world is almost never that clear-cut. The general advice of "don't optimize until you've measured" is still almost always correct.
- magicalhippo 8y ago
  > The general advice of "don't optimize until you've measured" is still almost always correct. The issue of course being that when designing code, various design choices can have significant performance implications, and can be very hard to change once implemented and in production.
abraae 8y ago
I'm saying there are very few real black and whites, and everything in life and in software is more kind of grey. As such there are very few black and white rules you can follow and succeed. The correct approach is somewhere to the left of "premature optimization" and somewhere to the right of "don't even think about performance until you can measure it". More experienced and talented people will be more successful at picking that sweet spot. Telling a dev that the correct approach is to pay absolutely no attention to performance before it can be measured is ... crazy IMO. I would expect them to have at least thought about it, and have some opinions, just as they should not have put excessive effort into prematurely optimizing things they don't know are going to be a problem. My point is - its grey, use your brains, don't buy into absolute rules.
- eleclady 8y ago
  Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.

by lbotos 8y ago

ams6110 8y ago

I think GP is saying, if you are at a point in development where you can choose A or B, and A has foreseeable better performance or scalability, all else being equal choose A. A lot of assumptions there and real world is almost never that clear-cut. The general advice of "don't optimize until you've measured" is still almost always correct.

magicalhippo 8y ago
> The general advice of "don't optimize until you've measured" is still almost always correct. The issue of course being that when designing code, various design choices can have significant performance implications, and can be very hard to change once implemented and in production.

abraae 8y ago

I'm saying there are very few real black and whites, and everything in life and in software is more kind of grey. As such there are very few black and white rules you can follow and succeed. The correct approach is somewhere to the left of "premature optimization" and somewhere to the right of "don't even think about performance until you can measure it". More experienced and talented people will be more successful at picking that sweet spot. Telling a dev that the correct approach is to pay absolutely no attention to performance before it can be measured is ... crazy IMO. I would expect them to have at least thought about it, and have some opinions, just as they should not have put excessive effort into prematurely optimizing things they don't know are going to be a problem. My point is - its grey, use your brains, don't buy into absolute rules.

eleclady 8y ago
Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.