[knorker]

It depends.

Run the lifetime cost of a CPU, and compare it to what you pay your engineers. It's shocking how much RAM and CPU you can get for the price of an hour of engineer time.

And that's not even all! Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent.

And if it has a bug because it sacrificed some simplicity? That's human hours or days.

And that's not even all. There's the opportunity cost of that engineer. They cost $100 an hour. They could spend an hour optimizing $50 worth of computer resources, or they could implement 0.1% of a feature that unlocks a million dollar deal.

Then having them optimize is not just a $50 loss, it's a $900 opportunity cost.

But yeah, shipped software like shrinkwrapped or JS running on client browsers, that's just having someone else pay for it.

(which, for the company, has even less cost)

But on the server side: yes, in most cases it's cheaper to get another server than to make the software twice as fast.

Not always. But don't prematurely optimize. Run the numbers.

One thing where it really does matter is when it'll run on battery power. Performance equals battery time. You can't just buy another CPU for that.

[gpderetta]

> Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent.

yet piles and piles of abstractions are considered acceptable and even desirable while having significant negative effects on code readability.

[knorker]

Yeah, it doesn't have a simple answer that works for all cases.

Say you need to do some data processing from format A to B. There's already a maintained codebase for converting from A to C, C to D, and a service that converts individual elements from D to A. All steps require storing back onto disk.

For a one-time thing it'll be MUCH cheaper to do it the naive way reusing existing high level blocks, and going to lunch (or vacation), and let it run.

For a recurring thing, or a pipeline with latency requirements, maybe it's worth building a converter from A to B.

Or… it could be cheaper to just shard A and run it on 20 CPUs.

Let's say you have the expensive piles of abstraction, and creating huge waste. At my company one HOUR of engineer time costs about the same as 20 CPUs running for A YEAR.

This means that if you reduce CPU use by 20 cores, forever, then ROI takes a full year. Including debugging, productionizing, and maintenance you pretty much can't do anything in 1h.

Likely your A-to-B converter could take 1h of human time just in ongoing costs like release management.

And to your point about code readability: Sometimes the ugly solution (A-C-D-B) is the one with less code. If you needed the A->C, C->D, D->A components anyway, then writing an A->B converter is just more code, with its potential readability problems.

On the flip side of this: It's been a trend for a long time in web development to just add layers of frameworks and it's now "perfectly normal" for a website to take 10s to load. Like what the fuck, blogspot, how do you even get to the point where you realize you need a "loading" animation, and instead of fixing the problem you actually do add one.

Human lifetimes have been spent looking at just blogspot's cogs spinning.