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.
a screen refresh
|27 KB||150 bytes||1 MB||24 KB|
one trivial change
|1.4 MB||7.6 KB||60 MB||1.2 MB|
|7 MB||50 KB||400 MB||6 MB|
a line of code
|84 MB||460 KB||3,600 MB||72 MB|
a small change
|1600 MB||9 MB||72,000 MB||1.4 GB|
a significant change
|40 GB||0.2 GB||1,700 GB||35 GB|
a major change
|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.
Published bimonthly and distributed to more than 550,000 of the top IT managers, database administrators, and developers.
Contains technology strategy articles, sample code, tips, Oracle and partner news, how to articles for developers and DBAs, and more.