Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked


by radiantmatrix (Parson)
on Apr 21, 2008 at 16:40 UTC ( #681962=note: print w/replies, xml ) Need Help??

in reply to CPU cycles DO NOT MATTER!

If we're confining ourselves to optimizations that make a very small difference per-operation, then I'd generally agree that the vast majority of the time1, the CPU time doesn't matter.

On the other hand, the core of your argument is somewhat specious:

Anything you do needs to be measured in that light by the person paying you. Is it worth having my person spend 3 days here and 2 days there squeezing out performance? Or, is it worth just buying another machine and having my person actually spend time advancing my business? Because, there's an additional opportunity cost to squeezing performance cause you're not doing something else that actually makes money.

When you talk about lost opportunity cost, etc., you miss a major piece of the puzzle -- it might take me 3 days to find the best algorithm to use (and get it working), but that effort has zero ongoing cost. In fact, I can use what I learned the next time there's a related problem, and I won't be spending that same 3 days again.

However, adding a new server does have ongoing costs. You have to admin it, secure it, keep its software up to date. You also have to plan to replace it when it breaks or ages.

Choosing when and what to optimize is extremely complicated. I tend to agree with the Two Rules of Optimization (I think these are Knuth's?):

  1. Don't
  2. (For experts only) Don't yet

So, if I were to rephrase your advice, I might say this: don't worry about optimizing your code until it works, and even then only if there is really a performance problem. I may even add that sometimes adding resources2 is a better solution than optimizing code -- but I disagree that it's always a better solution.

Beware false absolutes.


  1. I don't like throwing around numbers like "99%" unless there's actually some data to suggest that number. At least as an estimate.
  2. CPU isn't the only limiting factor that people optimize for. There's also memory and disk usage, network bandwidth, and a myriad other things that fall under the "resources" umbrella.
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Replies are listed 'Best First'.
Re^2: CPU cycles DO NOT MATTER!
by sundialsvc4 (Abbot) on Apr 24, 2008 at 14:49 UTC

    “A better algorithm” is always going to be significantly faster; otherwise it's not a better algorithm.

    When I got started in this business, computer-cycles were a thing that had to be rigorously conserved. But it wasn't just the CPU; it was every part of the hardware. Things were smaller and slower. Algorithms had to be smarter just to get the work done. And it was done. (Imagine a timesharing computer with a 1.5 mHz clock and 512K of memory with 32 terminals attached to it, all being used to register a college of 5,000 students for classes ... with less than one-second response time to any request, even if every user hit the Enter key at precisely the same instant, as we actually confirmed.)

    Now, we've got an embarrassment of riches. We can throw hundreds of pounds of silicon at any problem. A great big free sand-pile. But there are still choke-points, and if those choke-points are not clearly taken into account by the algorithm, we'll have poor performance and 0.01% CPU-utilization. (The two often occur together.)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://681962]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2017-06-24 01:04 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (555 votes). Check out past polls.