
Time exchange rate - jaimebuelta
http://www.johndcook.com/blog/2014/08/17/time-exchange-rate/
======
pierre_massat
And what about spending time to optimize a end user's time?

~~~
cfallin
Yep, or even your own time if you run the program multiple times. E.g., if
your code is running on a thousand machines, that CPU-hour savings that cost
$0.05 now costs $50.00; past a certain point it _does_ pay to throw engineers
at insane micro-optimizations. Or nonlinear payoffs from CPU time improvements
-- e.g. meeting a realtime deadline or else the system is useless. The "CPU-
hour vs. engineer-hour" comparison works only when the engineer him/herself
runs their own program, exactly once, without other constraints.

~~~
matt_kantor
> The "CPU-hour vs. engineer-hour" comparison works only when the engineer
> him/herself runs their own program, exactly once, without other constraints.

Or when the system is designed such that you can scale hardware to decrease
run time. Sometimes the choice is between throwing programmer time at a
performance problem or throwing hardware at it, and often the economics work
out in favor of the latter.

~~~
cfallin
Sure, but I think this is just reiterating the original point that hardware is
cheap and programmers are expensive. If you need to meet a performance goal
and hardware is cheap but programmers are expensive, then throw hardware at
it. The point I was (trying to) make is that when you have N instances of the
problem to solve (where N is large), often the cost of "scaling the hardware"
is prohibitive; optimizing performance by 1% might yield operational cost
savings that justify the programmer's salary, simply because the 1% is
multiplied by N. This is orthogonal to parallelism/scalability.

I'll grant that this case may be rare (i.e. most people are optimizing for
initial results, not optimizing a large existing machine) but it does happen!

~~~
TeMPOraL
Of course it does happen, it's not a rare case, it's the usual case. Any
remotely successful product will have N = millions of users. The only reason
this doesn't enter the calculation is that you don't get the money you saved
by not making your users do unnecessary hardware upgrades.

~~~
cfallin
Ah! So there's the key point: do your users run your software or do you, on
your servers? If the former, yes, it's an externalized cost and may not enter
your economic calculations. If the latter, you care a lot :-)

------
fleitz
Yes! I can't stand this kind of thinking in code reviews, someone will say X
is slow, and I say, "How slow is it?" they'll say something about O(X) and
I'll say, no really exactly how much time in seconds will be saved by changing
this.

Usually at this point they have no answer.

In general your O(n^4) algo is perfectly fine, and no one will ever notice
your O(1) replacement. When it isn't fine it's painfully clear that it's not
OK.

------
retroencabulato
Cute, but there are a lot of situations where this breaks down. It assumes
that a programmer's efficiency is independent of a program's efficiency.

If I have to wait hours for a job to complete that could be completed in
moments with a bit of extra work, there certainly is value in working on the
optimisation.

------
TTPrograms
One metric I think about a lot in my work is the sum of runtime and
programming time, because I often write one-off analysis programs and just
care about when I get the results. It's nice because I can focus on the
sweeping optimizations and not the small ones.

