4 ms·
Early speed optimizations aren’t premature
- rurban 4y agoOf course. Just engage into mature speed optimizations from the beginning, as everyone else.
- mattkrause 4y agoThis article would be more convincing if the NumPy version were actually vectorized. Replace the for-loop with result = (arr - min_val) / (max_val - min_val) That should often run faster and removes the allocation and for-loop, so it's easier to read.
- itamarst 4y agoYeah this was a copy/paste mistake, I have fixed it.
- smodo 4y agoI wouldn't say using vectorized operations as opposed to for loops is such a good example. You're simply using the right tool for the job. Is using a fork to eat soup suboptimal? Is switching to a spoon optimizing the way you eat? But what about using a dict or a list or tuple? That kind of decision can make a performance difference down the road, and there are trade offs in ease of development. Anyway, the whole thing feels a little contrived. Who would ever argue that you shouldn't use numpy from the get-go? Who is the author arguing against?
- martinhath 4y ago> Who is the author arguing against? This is addressed in the third paragraph: > The problem with this saying is that many people wrongly interpret it as “early optimization is the root of all evil.” In fact, writing fast software from the start can be hugely beneficial.
- lupire 4y agoLike most comtrarian articles, it is only meaningful if you haven't read the original, which it isn't actually contradicting. https://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil/80092#80092 https://softwareengineering.stackexchange.com/questions/8008...