Hacker News Reader

Comment by cogman10 | Hacker News Reader

It's stuff like this that makes me mad when I see "Optimization is the root of all evil" quotes thrown at me.

The code I'm most typically fixing for performance isn't some complex algorithm that needs inline assembly and AVX register weaving... No, the kind of code I most often fix for performance is code where someone does `Double.parseDouble(foo.toString())` and turn it into `double bar = (double)foo;`.

Or code where someone does n^2 when they could have had n by using a dictionary/hashmap. Or code where someone uses a dictionary/hashmap instead of using a simple POJO.

It drives me bonkers when someone apparently goes out of their way to write code in the slowest form possible.

View on HN

Eh - It's good to know when you're taking the slow route, but most times the slow route is fine.

It's easy to point to the title piece and assume the right advice to is try to optimize early - but the reality is that the gains mentioned here basically only matter because these libraries are used by millions of developers, and run often.

essentially - don't try to optimize until you have a reason to make that effort worth it. For these libraries - it's worth it.

For the times you're getting asked to fix performance, it's because performance has become a feature that matters enough to have someone ask you to fix it. It's fine to wait until that time to swing back around and pay attention to it. There are thousands of times where that never happens, because the performance was fine taking the scenic route through a string. Plus - that leaves you plenty of low hanging fruit to pick up some easy wins.

---

I think the real story here is not that folks are taking the slow route, I think the story is that the low hanging fruit hasn't been knocked out of these libraries. And really, that goes to show that a lot of software really is supported by a very small number of library authors, who aren't doing it as their day job, for very little in the way of real compensation.

Ex: SVGO is used by 9.1 million people (on github alone) but only has 163 contributors, and only 4 people have more than 10 commits. That means only one in 55,000 users has bothered to add anything. And there's only one real dev for every 2.25 million users. And "users" here also includes entire companies.

It's fine to not optimize from the start, but the examples they gave are of cases where the code is doing something more complex that's also slower.

Don't make your solution more complex than it needs to be. Start with the simplest solution and you will often get a faster solution as a side effect.

I disagree with this take. In both examples (the original article, as well as the one posted right above) the code under review was slow but simple.

Taking just the two from the comment right above this:

  Double.parseDouble(foo.toString())

This will work for basically any possible value/type of foo, assuming foo supports .toString(). It will work for NaN, it will work for infinity, it will work if the value is already a string.

It's explicitly avoiding the complexity of having to consider those cases at programming time, in exchange for taking the slow route (code someone else has written to already do that for you).

Simply casting to double will probably work, but not always - worse, the warnings you get, and the edge cases you might need to deal with will vary significantly across languages. Ex: Java will do different things than C++, which will do different things than C#, Python will vary by flavor (CPython and Jython use different underlying types).

Basically - it's saving the programmer a boat-load of complexity (reduces the edge cases down to just the exceptions parseDouble() might throw), in exchange for doing something slow.

---

Take the hashmap example right after the double example. Will a hashmap let you speed up some algorithms by avoiding n2 in favor of n? Sure - at the expense of memory size and longer initialization. In most places that's probably a sane call. Is it always the right call? Nope. Would not be ideal for my arduino - the memory is so limited n2 is unlikely to matter most times, and again - the memory is so limited I'd rather go slow and finish than try to go fast and segfault.

It's also not the right call when the expected length of the data is always going to be small values of n. If n is always going to be less than 5, I'd bet you good money the hash implementation will be slower in most cases.

----

Basically - optimize when optimizing becomes important, because something is slow and it sucks. Until then... slow is smooth and smooth is fast.

> This will work for basically any possible value/type of foo, assuming foo supports .toString(). It will work for NaN, it will work for infinity, it will work if the value is already a string.

A) the example above was explicitly for int -> double, so the fact that it the path through .toString will work for other types is a benefit we won’t get but which has a cost we’ll have to pay regardless.

B) I find it hard to believe that the Double class doesn’t my have a method you could call which will convert an int and catch NaN, Null, and MaxInteger.

> In most places that's probably a sane call. Is it always the right call?

Just as you’d bet that the hash implemention will become slower, I bet you that only 1 in a million people (if that) would write the Double code we’re talking about as the result of thoughtful consideration.

> optimize when optimizing becomes important, because something is slow and it sucks. Until then... slow is smooth and smooth is fast.

Slow is smooth assumes that the slow path you pick is sane.

There’s also a big difference between having to write code that needs optimization, and writing less code to do a job faster.

> the example above was explicitly for int -> double

?????

Show me where the type of foo was defined in that comment... I'll wait.

For all we know it was some god-awful custom bucket/container class that's hiding all sorts of polymorphism from you.

There’s no black and white. I’ve known really good optimizers who do harm to the company and their peers by obsessing over gains that simply don’t matter.

And I’ve known people who make programs unnecessarily slow and painful because of sloppiness.

That’s not to say you can’t endeavour to “do it right the first time” but very regularly that is not a realistic goal.

Good engineering requires understanding the big picture, particularly what matters and doesn’t matter to a business (and how those priorities change over time).

Yeah, I generally favor the approach of first making the code easy to understand/validate, and easy to replace later if you find a performance problem. I’ve found it’s usually only a small percentage of the time that your first guess for what’s going to be a bottleneck is accurate.

Engineering has pretty much always been the art and science of "good enough". Anyone can make a bridge with infinite resources, but an engineer is who can make a bridge just good enough to not fall down within budget and spec.

The challenge with software is the underlying "physics" of our world continue to get more powerful year over year (unlike real physics), so "good enough" ends up being sloppier and sloppier as time goes on, and for a lot of applications it doesn't matter.

Of course, until that day where it turns out it does matter. Good developers I think can anticipate some of those cases, and great developers can pick the few that they can sink the time into getting Right (tm) (c) 2022, to get the most bang for their (time) bucks.

wait wait wait, the actual quote is "PREMATURE optimization is the root of all evil". Completely different meaning

We also shouldn't forget the full quote

“There is no doubt that the holy grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”

— From “Structured Programming with go to Statements” (Knuth, 1974),

> It drives me bonkers when someone apparently goes out of their way to write code in the slowest form possible.

We used to call that BASIC.

I just yesterday found a case in my codebase of linear searching dict.keys() for the dictionary key.

I had a candidate try that in an interview with me yesterday.

Reply on news.ycombinator.com