3 ms·

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. "Prematur

by 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.

by jerf 4y ago

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.