4 ms·

I'd take "premature optimization is root of all evil" type of advice with a big grain of salt. IMO it's sensible for procedures, since they can often be optimiz

I'd take "premature optimization is root of all evil" type of advice with a big grain of salt. IMO it's sensible for procedures, since they can often be optimized rather quickly. It's NOT sensible if you designing the application's basic data structures AND have an idea about the scale you want to achieve, which for data heavy applications is often the case (e.g. you know the rough file sizes that go into your importer beforehand). From personal experience, once #records times #fields goes into the millions, it starts to make sense to think about a data centric design. Functional interfaces are perfect to encapsulate e.g. a bag of arrays and not expose it to all the rest of your application.

jerf 4y ago
If you are designing your application's basic data structures and have an idea about the scale you want to achieve, the optimization is not premature. "Premature" isn't a decorative word, it's doing real work in that phrase. There are plenty of people reading this article right now and going yeah, yeah, this is exactly what I need! while their task is writing an API that will receive 3 requests per minute that run in less than ten milliseconds each. We don't warn against "failing to optimize when it is needed" not because it isn't a problem, but because historically the bigger problem has been premature optimization. (I phrase that carefully, because I'm not sure the balance isn't shifting. I feel like I'm seeing more failure to do basic optimizations lately than people going crazy prematurely optimizing. I've started lightly banging on this drum and in 10 years we may need a luminary to say something like "FFS, people, adding up a few thousand integers shouldn't take three seconds! How did you even make your code that slow??", only, you know, pithily and quotable. But I can vouch for the fact that historically, going all the way back to when Knuth said that, premature and excessive optimization has been the bigger problem.)
- m_mueller 4y ago
  There are definitely problems on both end of the scale, but I’m seeing more of the former definitely - I think it depends a lot on what kind of environment you’re in. I more often encounter people using “premature optimisation” to not do any optimisation at all. It results in applications that have a much lower performance ceiling and more often require a rewrite relatively soon. Edit: I also want to add that in this specific case with Java, using functional interfaces with primitive datastructures often doesn’t really have any downside. If you know you need to filter the data to a lower scale first before continuing (e.g. to the amount you can display on one page), it’s just not sensible to object box your entire data first, just so you can avoid having arrays anywhere in your code. Just have a class for your data and expose some rich interfaces to it, but implement paging on top of primitive data in this case.
jt2190 4y ago
> I'd take "premature optimization is root of all evil" type of advice with a big grain of salt. Instead of responding by making this a conversation about “premature optimization”, we might do better by remembering that the Java runtime’s HotSpot compiler does apply automatic optimizations around instance creation. Instead, we should make sure that (a) we haven’t accidentally taken a bad time measurement because we haven’t given the runtime enough time to see the slow parts of our code and apply it’s optimizations, and (b) that we haven’t accidentally written code that the runtime can’t optimize. Edit: Perhaps after all of that we still have slow code, but at least we’ve made sure we’re keeping an eye on all of the JVM’s moving parts as we craft our solution.

jerf 4y ago

If you are designing your application's basic data structures and have an idea about the scale you want to achieve, the optimization is not premature. "Premature" isn't a decorative word, it's doing real work in that phrase. There are plenty of people reading this article right now and going yeah, yeah, this is exactly what I need! while their task is writing an API that will receive 3 requests per minute that run in less than ten milliseconds each. We don't warn against "failing to optimize when it is needed" not because it isn't a problem, but because historically the bigger problem has been premature optimization. (I phrase that carefully, because I'm not sure the balance isn't shifting. I feel like I'm seeing more failure to do basic optimizations lately than people going crazy prematurely optimizing. I've started lightly banging on this drum and in 10 years we may need a luminary to say something like "FFS, people, adding up a few thousand integers shouldn't take three seconds! How did you even make your code that slow??", only, you know, pithily and quotable. But I can vouch for the fact that historically, going all the way back to when Knuth said that, premature and excessive optimization has been the bigger problem.)

m_mueller 4y ago
There are definitely problems on both end of the scale, but I’m seeing more of the former definitely - I think it depends a lot on what kind of environment you’re in. I more often encounter people using “premature optimisation” to not do any optimisation at all. It results in applications that have a much lower performance ceiling and more often require a rewrite relatively soon. Edit: I also want to add that in this specific case with Java, using functional interfaces with primitive datastructures often doesn’t really have any downside. If you know you need to filter the data to a lower scale first before continuing (e.g. to the amount you can display on one page), it’s just not sensible to object box your entire data first, just so you can avoid having arrays anywhere in your code. Just have a class for your data and expose some rich interfaces to it, but implement paging on top of primitive data in this case.

jt2190 4y ago

> I'd take "premature optimization is root of all evil" type of advice with a big grain of salt. Instead of responding by making this a conversation about “premature optimization”, we might do better by remembering that the Java runtime’s HotSpot compiler does apply automatic optimizations around instance creation. Instead, we should make sure that (a) we haven’t accidentally taken a bad time measurement because we haven’t given the runtime enough time to see the slow parts of our code and apply it’s optimizations, and (b) that we haven’t accidentally written code that the runtime can’t optimize. Edit: Perhaps after all of that we still have slow code, but at least we’ve made sure we’re keeping an eye on all of the JVM’s moving parts as we craft our solution.