You might say that at my company, the hard ware is 10x more expensive, but it also likely you time is costing the company about the same more.
In any case, this article attempts to demonstate that there is a tipping point where it no longer makes sense to spend time saving memory, or even thinking about it.
| time spent | cheap memory | expensive memory | cheap disk | expensive disk |
|---|---|---|---|---|
a screen refresh 20 ms | 27 KB | 150 bytes | 1 MB | 24 KB |
one trivial change ~1 sec | 1.4 MB | 7.6 KB | 60 MB | 1.2 MB |
one command ~5 sec | 7 MB | 50 KB | 400 MB | 6 MB |
a line of code ~1 min | 84 MB | 460 KB | 3,600 MB | 72 MB |
a small change ~20 min | 1600 MB | 9 MB | 72,000 MB | 1.4 GB |
a significant change ~1 day | 40 GB | 0.2 GB | 1,700 GB | 35 GB |
a major change ~2 weeks | 390 GB | 2 GB | 17,000 GB | 340 GB |
Your mileage may vary, but just today some one asked how to save a few bytes by passing short instead of int as method arguments (Java doesn’t save any memory if you do) Even if it did save as much as it might, the time taken to ask the question, let alone implement and test it, could have been worth 10,000,000 times the cost of memory it could have saved.
In short; don’t fall into the trap of a mind boggling imbalance of scale.
Reference: Wasting time by saving memory from our JCG partner Peter Lawrey at the Vanilla Java blog.
