Hacker News Reader

Comment by pdpi | Hacker News Reader

Introduce them to the concept of static single assignment form, and how it is an intermediate form that enables a tonne of downstream optimisations. Most of those "wasteful extra variables" would be introduced by the compiler anyway, so it's not a problem.

Alternatively, just ask them to prove it. If it's faster, they can benchmark before and after, and prove that it's faster? No proof means you're full of shit. This is the Right Answer in that it's what you should be doing anyhow to avoid performance regressions, but it's way more combative and can cause problems within the team, so must be done tactfully.

View on HN

> If it's faster, they can benchmark before and after

That goes bad very fast. I've worked with someone who tried winning arguments with one-line microbenchmarks; They even tried to convince me that I should always use undefined over null in JS since one is faster than the other (forgot which).

> Introduce them to the concept of static single assignment form

I failed with this as well; some coders don't trust the compiler/runtime at all. I had people tell me that garbage collectors don't deal with cyclic dependencies or that "simple comparisons" (<, >, ==) are faster than "compound comparisons" (<=, >=).

Craziest one I remember from my Java years (long long ago) was someone claiming that returning values by throwing exceptions and catching them to extract the return value was faster than simply returning the value....

This was wrong on a number of levels.

Oh come on, this is obvious. Thrown things are fast. Anyone who's ever rented a VHS tape from Blockbuster knows that returning something can take days. Of course he's right.

Also, I once worked with who someone who mixed up exit() and C return in a library he wrote....

To be fair, they must have been full on bats--t insane.

To be fair, in R on my machine > and < seem to be faster than ==, at least for integers. But the difference is miniscule compared to the overhead of doing just about anything else.

At best the benchmark results will be answered with "the compiler got lucky that time." Someone like that needs to understand the details of the error in their thinking along with multiple benchmark examples proving it.

Reply on news.ycombinator.com