There are a lot of problems which the engineer in me wants to code around that should really, really be solved by throwing money at it. Often, a trivial amount of money.
I once did several hours of work trying to optimize my use of Redis to avoid having to upgrade my VPS (I was nearing the limits of the physical memory at 1.5 GB). I even asked Thomas for advice on how to decrease memory usage. His reply: "How much to the next tier?" "$30 a month." "Why are we having this conversation?" And, of course, he was right.
better code (algorithms, performance, memory usage) is amortized across the life of the rest of the system. fixed-cost upgrades will eventually be caught up to. so it's not bad to think like that.
You can use the freed-up engineer time to write better code which you can also keep for the life of the system though, though. It is not too hard to think of things which you could do in a few hours that would pay for RAM upgrades in perpetuity, even at BCC's relatively small scale. (Say, an A/B test which resulted in a 1% lift on my AdWords landing pages.)
It's precisely BCC's small scale that makes spending engineering time on performance optimizations expensive. At Google's scale it's worth several thousand engineers' time.
Really, you just have to weight the cost of the upgrades against what that time is worth. A week of engineer time is cheap compared to upgrades if your code runs on hundreds of thousands of machines.
this is true, but over the lifetime of most systems, resource usage is going to go up at some linear-ish rate, no matter how efficient the code is. its not worth the time trying to fight that hard bottom line increase. if things are wildly out of control, sure, fix the code. but if you've been running your app for 5 years on the smallest VPS and you're pushing the need to upgrade, your time is probably best spent elsewhere.
It's often easy to forget that developer time == money. Any problem you can solve with an application of less money than an hour equivalent of developer time is often not even worth talking about unless it's just a symptom of a bigger issue.
Especially keep this in mind with regard to meetings. A half-dozen people in a meeting burns up about a day of developer time in cost every hour they meet.
And sometimes developer time now is much more valuable than developer time X months later. If you can put off the performance improvement by throwing money at it, this might be a big tactical win.
It can certainly be used as an excuse for laziness, it needs to be weighed along with anything. Optimizing an algorithm in a method that only gets used rarely and that only ever handles a tiny amount of data is a waste of time.
Sometimes O(n^2) algorithms are ok even when O(log n) alternatives exist. If it takes a trivial amount of time to write the slow algorithm whereas it would take a lot more time to write the better one and if you can guarantee the input complexity the algorithm will handle won't exceed a certain range, then it's fine.
Consider a factorial function for integer input & output, for example. What's the best way to implement such a thing?
It actually doesn't matter. The most important aspects are to get the error handling and input bounds assertions right, because 21! is larger than 2^64, and the difference between recursion, iteration, and caching at that scale is probably just noise unless you are calling the function thousands or millions of times a second.
P.S. This is a good reason why clear documentation outlining design decisions and their rationale is important. When someone decides to take some pre-existing code that "works great" and massively expand how it's used without changing it the result can be disastrous if people haven't taken into account the inherent limitations of that code.
> There are a lot of problems which the engineer in me wants to code around that should really, really be solved by throwing money at it. Often, a trivial amount of money.
On the other hand, I once saw a project where people seemed to want to use a non-SQL database to store about a hundred megabytes of metadata a year. They also want to use S3 for a couple terabytes of content instead of a filesystem.
Throwing money on a problem that doesn't need to be solved, just because you can, is tempting.
I once did several hours of work trying to optimize my use of Redis to avoid having to upgrade my VPS
I would think RAM preservation would be a much greater concern in the VPS world as the hard limits are ever present, and quickly become enormously expensive.
In the dedicated server world it isn't quite as prohibitive. An R810 can be had with 512GB. Just got several new servers to add to the mix, each with 144GB of memory.
Though of course I eminently disagree with Atwood's statement about algorithms. In fact I think he doesn't believe that either, but it was just a bit of color on the entry.
Circumstances can make the benefits of tweaks and performance improvements in this particular field evaporate anyway. Too much of the work involved makes the effort expended rarely worth it unless your whole business is app deployment or you're Google.
I once did several hours of work trying to optimize my use of Redis to avoid having to upgrade my VPS (I was nearing the limits of the physical memory at 1.5 GB). I even asked Thomas for advice on how to decrease memory usage. His reply: "How much to the next tier?" "$30 a month." "Why are we having this conversation?" And, of course, he was right.