Code Tuning: Speeding Up Computer Programs

From some of my recent readings in the reading materials from the university, I have come across this rather curious term: code tuning. It should not be a new term so, what makes it curious is the fact that I haven’t heard from anyone or read about it anywhere else before.

Of course, it is undeniable that going for a better algorithm is highly important to reducing the demands of a program. But, code tuning can also help in improving the running time of a computer program. This is because code tuning is simply the manual optimization of a program to make it run faster and smoother, just like tuning a car engine.

Similar to when a person tunes a car engine by removing quirks, replacing old parts with new and better ones, and even just cleaning the engine, code tuning is done in the same vein.

More than just speeding up programs, code tuning also helps your code become more readable and understandable to not just the compiler or the interpreter but also to other coders who might need to be looking into your code or even just those who are simply interested in your code.

So here are some suggestions for ways to speed up programs with code tuning:

  • The most important thing to realize is that most statements in a program do not have much effect on the running time of that program. There are normally just a few key subroutines, possibly even key lines of code within the key subroutines, that account for most of the running time. There is little point to cutting in half the running time of a subroutine that accounts for only 1% of the total running time. Focus your attention on those parts of the program that have the most impact.
  • When tuning code, it is important to gather good timing statistics. Many compilers and operating systems include profilers and other special tools to help gather information on both time and space use. These are invaluable when trying to make a program more efficient, because they can tell you where to invest your effort.
  • A lot of code tuning is based on the principle of avoiding work rather than speeding up work. A common situation occurs when we can test for a condition that lets us skip some work. However, such a test is never completely free. Care must be taken that the cost of the test does not exceed the amount of work saved. While one test might be cheaper than the work potentially saved, the test must always be made and the work can be avoided only some fraction of the time.
  • Be careful not to use tricks that make the program unreadable. Most code tuning is simply cleaning up a carelessly written program, not taking a clear program and adding tricks. In particular, you should develop an appreciation for the capabilities of modern compilers to make extremely good optimizations of expressions. “Optimization of expressions” here means a rearrangement of arithmetic or logical expressions to run more efficiently. Be careful not to damage the compilerโ€™s ability to do such optimizations for you in an effort to optimize the expression yourself. Always check that your “optimizations” really do improve the program by running the program before and after the change on a suitable benchmark set of input. Many times I have been wrong about the positive effects of code tuning in my own programs. Most often I am wrong when I try to optimize an expression. It is hard to do better than the compiler.

Most of the time and space improvement that can be gained from better code still springs from a better data structure or algorithm. Therefore, it is important to always note to:

First tune the algorithm, then tune the code.


From Clifford A. Shaffer’s A Practical Introduction to Data Structures and Algorithm Analysis Edition 3.1 (Java Version)

Advertisements

Unclosed: Ending the Hiatus

hiatus*
A hiatus is a pause in which nothing happens, or a gap where something is missing.

It’s been about a year since I posted that previous post. It is about that time when I didn’t know what to do with the blog anymore.

I started blogging at a different WordPress page, J’s log, at jauntyskipper.wordpress.com. That was even a few months before the hiatus. It’s a page full of tumblelogs. A page of posts that will be considered asides if put in this same page.

I like it in there, too. I put down thoughts in there. Words I deem worth quoting from any one of my readings. Things I notice in the world around me that I consider worth putting into words. Passing thoughts. Ideas. Pieces of code. Just whatever. It is a tumblelog of just about all things I come across that I had the time and chance to put down.

However, this page has been started. And it’s somehow remained alive despite the huge break in the posts. I realized it’ll be a total waste if I simply abandoned this page.

And somehow this time seems like a good time to start posting again. To begin with, I’m posting something new that can be read about in this page. Of course, I’ll still be writing about the old stuff. But it never hurts to expand your reach.

* Definition taken from “Collins Cobuild Advanced Dictionary of English” ยฉ HarperCollins Publishers 2009