Over a million developers have joined DZone.

Saving Bytes

DZone 's Guide to

Saving Bytes

· Performance Zone ·
Free Resource

In the good old days we were hacking Z80 machine code and we were writing Assembly on paper. I had a laminated card with all the opcodes and I had to look up the codes from the card and write them on the paper along with the Assembly. The calculation of relative jumps was also a good practice, which is nowadays extinct. In my third year I wrote a small booklet on Z80 programming with some sample programs and explanations that was replicated in the official printer factory of the University. PDF, email? It was late 1980. I used Tasword. Can any of you recall that?

Those days we competed to see who could write the shorter program for a given problem. There were many tricks that we could use to save bytes. We created code that used the byte offset of the jump instruction as an opcode depending on where the program was coming from and the decimal BCD correction instructions in totally different ways than they were supposed to be used. Good old days.

These days we don't need to save bytes and I am happy about that. We can focus on problems that make more sense at a higher level. These low level issues are to be solved by compilers and loaders and, after all, we have plenty of memory these days. My Mac has 8GB of memory, which is 175,000 times more memory than the ZX Spectrum had. If we were to line up that many Spectrums side by side on the road it would stretch 38 miles. And the compilers and optimizers also know this and they are not keen on spending much CPU time to find clever ways to compress the program. So far so good. Usually.

Some days ago on a forum I was discussing clean code practice with some guy and I said that any method argument variable in Java should be final, and that it is a good practice to write the final keyword in front of each argument variable and it is a language design flaw that these variables are not final by definition. The reply was that some of the variables are altered and in this case a new local variable is to be used. Waste of memory? Well, yes and no. The JIT compiler in HotSpot JVM will optimize that. “Too late” the answer came. By the time the JIT optimizes the JVM code it was already loaded into the limited memory phone. And javac does not optimize too much because that would be premature optimization.

So are we saving bytes again? Unfortunately, no. The compiler and the other tools are designed for the major uses. Niche use should use niche tools if they exist. Some do. But then phones also tend to have enough memory to accommodate our code. Then the vacuum cleaners will come, and the light switches. But at some point all memory shortage will disappear, no? Well, I have to say no. Memory, perhaps. Then comes the bandwidth shortage. You will want to download some program to your personal spaceship that is two hours at light speed away, close to Jupiter. Hand shaking, error corrections, lag … bytes count again. Then this is solved later and something new comes, perhaps some swarm effect in hyperspace that we can not even imagine today.

What is the moral? No matter what happens, old technologies and tricks come back from time to time. They will perhaps have slightly different format, but the root problem is always the same: don't waste resources. Save the trees, eat … whatever.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}