Coming from an embedded background gives you a very different perspective on things. I too have a strong embedded programming background. This, among other th

Coming from an embedded background gives you a very different perspective on things. I too have a strong embedded programming background. This, among other things, makes you keenly aware of the CPU and resource cost of your code. If you've ever spent a day hunting for clock cycles to trim you know how that one can affect run time dramatically with a little attention. After a while this sort of thing becomes second nature. I think the C solution I posted is fairly tight: http://news.ycombinator.com/item?id=4327004 http://news.ycombinator.com/item?id=4327004 It pre-computes all that can be pre-computed outside the loop and then, once inside the loop, it uses a calculated index to address the array. The index only requires a comparison and, if going in reverse order, a subtraction, which are computationally cheap. If absolute performance was the goal --at the expense of a few more bytes of code-- this could be tightened further. One of the problems with programmers that don't have a low-level background, and, in particular, those who grew-up, if you will, with object-oriented programming, is that they don't generally have a connection with the cost of their code. Object oriented programming is great for the programmer, but the computer doesn't need it. It exists purely for the programmer's benefit. The computer would execute functionally equivalent non-OO code just fine and much, much faster. Case in point: Objective-C classes. I forget where the stats are but I remember that in some cases things run 400 times slower if you use certain "NS" classes. Four hundred times slower is a pretty serious price to pay for human convenience. I wrote a genetic evolver for an iOS app I worked on. The initial code was done in full Objective-C on purpose. I wanted to see just how efficient the code could be made "using the Force". I then re-coded in nice-clean C. Wow! I don't have the data in front of me but I remember that it went from having to wait for a solution to executing hundreds of generations (and arriving at a solution) almost as quickly as you retracted your finger after pushing the "Go" button. If we apply this to web programming it means that one could save a tremendous amount of money in server costs and provide a far more responsive system at the same time. Server costs go beyond the mere monthly cost of the hardware. Calculations should include MTBF, maintenance, power, cooling, etc. If you are using AWS these costs are all part of the package, of course. So, no, in my case, I don't take it lightly. I don't like it when people suggest that we "throw another server at it". First I want to see that the code is as tight and fast as can be. Then we look at throwing hardware at it. Of course, there is a point where hunting down clock cycles becomes more expensive than it is worth. The location of this point on the timeline is different for each business and project.