Hacker News Reader

Comment by sethammons | Hacker News Reader

A quote from one of our founders that I've always liked:

If you make an optimization that was not at a bottleneck, you did not make an optimization.

That's a bit broad i think, talking about pure speed of your task you are right, talking about energy consumption then it's not always the case. Or small but often repeated task should be optimized no mater if they are bottlenecks, when the system grows they will become bottlenecks, optimize like a Vulcan is what my boss once said...be logical and nothing else (my interpretation)

"optimize like a Vulcan"... classic!

Best boss ever!! He even had a bottle of his best whisky refilled in a bottle called "Saurian brandy", so everyone who said that this is illegal or ohh that's "start trek" got one...well not a bottle but a glas :)

Read The Goal by Eliyahu Goldratt. While it's possible your founder came upon the idea independently, this is one of many that are repeated in that book. It's relatively short and entertaining to read and has definitely survived the 36 years since first publishing quite well.

This is what instantly came to mind for me. Making a station faster generally only matters when it's a bottleneck.

It doesn't matter how optimized your computations are if you're spending the whole time waiting in IO. And don't forget that the program is generally just a piece of a larger process.

This was adapted into a novel about IT/devops called The Phoenix Project. It's an excellent read.

I second this. Quite the entertaining read, honestly. I also enjoyed the completely unnecessary transformation of the security dork into a security ubermensch.

I've read The Goal and The Phoenix Project. While I did enjoy the stories, I'm uncertain, perhaps due to inexperience, what the main lesson/s are supposed to be.

Anyone want to share their main takeaways from these books?

Reduce feedback cycles

That's less true when you're paying the cloud for compute by the second.

Not all optimization candidates are about bottlenecks. Reducing allocation is also optimization, for example.

Peak memory or garbage collection throughput can become a bottleneck. But if you know you have more memory than you need, further reducing allocation is arguably a waste of your time.

This can become a tragedy of the commons in desktop and mobile apps, where you don't know how much memory the end user has or needs, but you do know you aren't paying for it.

> But if you know you have more memory than you need, further reducing allocation is arguably a waste of your time.

This is absolutely not true. Just because you have enough memory does not mean that wasted memory couldn't be better used - e.g. for disk cache or to run more tasks.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

Except that there are infinite such non-bottlenecks, and all the effort you spend on there is effort not spent on the real bottlenecks.

In other words, all engineering is time- and cost-constrained. Anybody can build a good chair for $10,000 or a good PC for $100,000. Doesn't mean it's good engineering.

"Anybody can build a good chair for $10,000 or a good PC for $100,000."

And some people can build a great PC for $1,000 that runs circles around the good PC for $100,000.

There's so much more to engineering than thinking in terms of time and cost constraints. Those are real constraints, but they're not the most important.

Engineering is design. If you have good design, good insight, you can do things that people with infinite time and budget could never dream to achieve. You can start making a product that's a hundred times more powerful for a tenth of the price in a fraction of the time. If you don't have good design, good insight, then no amount of time or budget can help you.

Yes they can indeed: https://blogs.systweak.com/someone-has-built-a-gigantic-1000...

>not spent on the real bottlenecks

BE LOGICAL! Of course you first fix the big bottlenecks.

>good PC for $100,000. Doesn't mean it's good engineering.

Of course it is...or can you gold platter a pc case?

There are several assumptions that are far from a given with premature optimization.

1. Adding the optimization didn’t make the code more complicated.

2. Adding the optimization didn’t introduce a bug.

3. This part of the code will be a bottleneck in the future. The time spent optimizing is a write-off if the project is canceled or that portion is replaced.

All, true, but if you have a time budget and you know this thing will prevent you from meeting it AND making this change now will inform the architecture then its the right optimization to make.

Amdahl would agree.

Reply on news.ycombinator.com