Wasting time by saving memory
Overview
Memory and disk space is getting cheaper all the time, but the cost of an hours development is increasing. Often I see people trying to save memory or disk space which literally wasn't worth worrying about.I have a tendancy to do this myself, because I can, not because it is good use of my time. ;)
Costs for comparison
Cheap memory - You can buy 16 GB of memory for £28.Expensive memory - You can buy 1 GB in a phone for £320. (The entire cost of the phone)
Cheap disk space - You can buy 3 TB of disk for £120
Expensive disk space - You can buy 1 TB of the fastest RAID-1 PCI SDD for £2000.
The living wage in London is £8.55.
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.
except.. the cost of a memory module is a fraction of the cost of actually ordering and installing the memory for a server (+backup server) in a managed data center :)
ReplyDeletewriting code is often a fraction of the cost of testing., deploying and maintaining it.
ReplyDeleteit is worth noting that space is reusable buy your time is not.
often the real reason for a lack of comparison is that your costs are committed and from a different budget. the hardware costs are seen as optional and relatively expensive to approve.
your mileage will vary but even if the figures are 10x or 100x there is always a point where it doesn't make sense try to save the last byte or possibly even MB.
From the other hand - it doesn't work if you can not enforce clients to buy more memory. Mobile aps, software products, etc.
ReplyDeleteExactly. That's not just about your money, but also about your client's money and hardware : if you deliver your applications, you cannot say to your clients "hey, I don't want to waste money trying to save memory / disk space, just buy some more RAM / Disk space". That does not work (yeah yeah, we tried it).
DeleteActually, I think that your article only applies to particular situations where the company hosts its applications on its servers. Then yeah, buying some more RAM is not expensive.
I think that developers should always know if a particular part of their code is going to use a lot of memory. That's not just a matter of money but also a matter of good practices
I am making the assumption here that the relationship is linear.
DeleteIn reality, an application's memory use can be a) not a problem b) of concern c) too much.
In the case of c, you have the option of buying more memory, but this may be difficult to sell if people are not used to the idea of memory as a consumable. i.e. like paper for a printer.
However, is its b and your memory consumption is workable but should be lower there is a trade off point, depending on your applications usage. Note: if you install the software on 1000 machine then saving 1 MB each is 1 GB overall.
If the situation is a, and saving memory doesn't help the client or you for that matter, then it really could be a waste of time regardless of how much you can save. i.e. it adds risk as it could introduce a bug, for no gain.
Rather than saying that saving memory is good practice, I would say effective use of resources is good practice and there are many good practices which result in saving memory, but it shouldn't be a goal in itself unless there is a clear reason to do so.
I agree. It depends on specific situation. In most cases I would prefer to save time instead of consumed memory. By the way, more interesting example is when we have to sacrifice performance to make code simpler and more understandable.
DeleteI would say that sacrificing performance to write simpler, clearer, cleaner code happens less often than you might think as the JIT and the CPU can optimise simpler, clearer code more readily.
DeleteI would not misconstrue Peter's comments as to write sloppy code and expect your customer to solve any performance issues by purchasing additional hardware.
ReplyDeletePeter's example above says it all, inexperienced developers more often than not try to optimize their application's performance by writing code that is difficult to read (bit-flips, using short instead of an int) and they end up sacrificing code-readability. Unreadable code is the worst thing that could happen to your application, it makes your application expensive to maintain. Once your application has gone into maintenance mode and you want to hire that cheap college intern to work part time and maintain the code, he/she will come in and will have no clue why Joe X. added a particular line of code 5 years ago, Joe left the company and nobody can tell you what that code does...
Instead, opt to write clean, readable code, use standard algorithms to improve performance and let the JVM do its work of optimization.
I agree with these comments. There is a a trade off point where saving memory is a good idea, even at the expense of clarity, but that trade off point is much higher than many people assume it is and generally, for server based code in particular, it is better for the code to be simple and easy to maintain.
Delete