4 ms·

Ironically, complaining about the elegant solution of padding the array with "well this is going to suck on a multi-gigabyte in-memory dataset" is pretty much t

by efdee 8y ago

Ironically, complaining about the elegant solution of padding the array with "well this is going to suck on a multi-gigabyte in-memory dataset" is pretty much the definition of premature optimization. Chances are very high his dataset is not multi-gigabyte in-memory.

dahart 8y ago
Not really. Making a one-time allocation for a linear pass through an array is almost always bad. It’s often just as bad for many small arrays as it is for one big array. The idea to not prematurely optimize was never intended to be a free pass to use wasteful practices everywhere until there’s a horrible problem, it’s more about avoiding factoring your code into something you can’t maintain. Generally speaking, baking your corner cases into your precondition code is more dangerous than avoiding allocations. The idea was also not to leave concerns about performance completely off the table until your application is correct; it is assumed that you are making somewhat reasonable choices for your unoptimized code and your architecture, not that you are actively trying to slow things down with unnecessary allocations.
deleted 8y ago
[deleted]
DarkWiiPlayer 8y ago
I disagree with two points of what you said. The first is that you call something that copies an arbitrarily long memory section to avoid two ifs "elegant", the other is everything else. Elegant code uses less instructions, clear structure and is in general one of the better implementations in terms of performance. The suggested implementation shifts the workload into standard ruby functionality, but multiplies it by many times in the process; turns the clear structure of two conditionals into weird data trasnformations that and ultimately performs much worse than just the two extra ifs. The multi-gigabyte-dataset was obviously an extreme example (yet one that may very well happen in practice). The point is, bad code like that is inevitable going to slow down an application, the question is whether you care about speed at all. Arguably, if you're using ruby, you probably don't. Premature optimization usually refers to taking straight-forward code and making it more complex based on certain performance assumptions, like unrolling loops or writing inline assembly. This is bad because, well written code is most of the time fast enough, and if it does need optimizations, that will become clear soon enough. Choosing not change your code in a way that considerably impacts performance based on ones individual perception of cleverness and elegance, however, is not an optimization; it's avoiding a dumb mistake that will bite you in the ass later on.

by efdee 8y ago

dahart 8y ago

Not really. Making a one-time allocation for a linear pass through an array is almost always bad. It’s often just as bad for many small arrays as it is for one big array. The idea to not prematurely optimize was never intended to be a free pass to use wasteful practices everywhere until there’s a horrible problem, it’s more about avoiding factoring your code into something you can’t maintain. Generally speaking, baking your corner cases into your precondition code is more dangerous than avoiding allocations. The idea was also not to leave concerns about performance completely off the table until your application is correct; it is assumed that you are making somewhat reasonable choices for your unoptimized code and your architecture, not that you are actively trying to slow things down with unnecessary allocations.

deleted 8y ago

[deleted]

DarkWiiPlayer 8y ago

I disagree with two points of what you said. The first is that you call something that copies an arbitrarily long memory section to avoid two ifs "elegant", the other is everything else. Elegant code uses less instructions, clear structure and is in general one of the better implementations in terms of performance. The suggested implementation shifts the workload into standard ruby functionality, but multiplies it by many times in the process; turns the clear structure of two conditionals into weird data trasnformations that and ultimately performs much worse than just the two extra ifs. The multi-gigabyte-dataset was obviously an extreme example (yet one that may very well happen in practice). The point is, bad code like that is inevitable going to slow down an application, the question is whether you care about speed at all. Arguably, if you're using ruby, you probably don't. Premature optimization usually refers to taking straight-forward code and making it more complex based on certain performance assumptions, like unrolling loops or writing inline assembly. This is bad because, well written code is most of the time fast enough, and if it does need optimizations, that will become clear soon enough. Choosing not change your code in a way that considerably impacts performance based on ones individual perception of cleverness and elegance, however, is not an optimization; it's avoiding a dumb mistake that will bite you in the ass later on.