optimising : Java Glossary

optimising

Optimising, sometimes called tuning or fine tuning is the art of making computer programs run faster. It is also the art of finding the optimum tradeoffs between ease of maintenance, simplicity, terseness, speed, portability, low RAM (Random Access Memory) usage and quickness to get the app working in the first place. Don’t go crazy with optimisation. If you spend an extra man-week on a project optimising, over the lifetime of the project, you had better save at least a man-week of other people’s time waiting for the program, and you must consider that you have deprived those same people of using your program a week earlier.

We should forget about small inefficiencies, say about 97% of the time: premature optimization is the root of all evil.
~ Donald Ervin Knuth (born: 1938-01-10 age: 74)

A fast program is not as important as a correct one.
~ Steve McConnell

The only result of optimization you can usually be sure of without measuring performance is that you’ve made your code harder to read.
~ Steve McConnell

Jackson’s rules of Optimization:
Don’t do it.

(For experts only) Don’t do it yet — that is until you have a perfectly clear and unoptimized solution.
~ M.A. Jackson

How to Proceed

If you have a program that is running too slowly, here is what to do. I suggest following the steps in this order:

Get someone experienced in these matters to look over your code and find out where it is spending all its time. It helps to have a fresh pair of eyes on the problem. They will use a profiler to determine this. This identifies the bottlenecks.
Look at the bottleneck code for obvious blunders and correct them.
See if there is a totally different faster algorithm for accomplishing the same thing, e.g. hashMap vs linear searching a long table.
Clean up the bottleneck code to ship shape. This is not considered optimising, just getting it squeaky clean with no rambling.
See if the program is recomputing anything. Perhaps it can avoid redoing work it has already done. The form of optimisation tends to make the code more complex and less maintainable, but not always. Sometimes inexperienced programmers call methods where they are not needed at all, and that code can be yanked out entirely.
Consider the use of a native optimising compiler such as JET.
If all else fails try JNI with C/ C++. Beware. JNI (Java Native Interface) only saves you CPU (Central Processing Unit) time if you can do a substantial amount of work in C/C++ on each call to offset the high overhead of the call.
If even that fails try JNI with assembler.
If that fails, tell your customers they will need bigger iron.

What Not To Do

Fools do by hand what a smart compiler will do for you automatically. This just makes the code harder to read and maintain.
Fools spend hours and hours fine tuning a method that is used only once per session. There is not much point in optimising anything other than the innermost loops. Typically 80% of the execution stays confined to 20% of the code.
Fools carefully shave every nanosecond off a BubbleSort implementation. You are much better off to seek out a better algorithm that scales well, and even better to find a canned solution written by some expert on the matter.
Fools buy a new computer twice as expensive as the old one just so that some program will run decently fast. Usually fine tuning just a few methods in the inner-most loops will give you a huge boost in speed. Consider judicious use of native methods in C or assembler, considering however the huge Java overhead to call them.
Fools fail to encapsulate so that if it turns out a technique is too slow, it means a total rewrite to substitute a more efficient one.
Fools are great believers in NIH (Not Invented Here) syndrome. Instead of using canned solutions provided by others, fools rewrite everything in a custom fashion to gain a tiny increment in execution speed.
Fools don’t measure the results of their optimisations to ensure they actually speed things up. Converting a huge Java method to a few lines of assembler can actually slow it down!
Fools don’t think about the tradeoffs. Highly optimised code is usually less portable, harder to maintain, and of course takes much longer to write. It should be used sparingly and judiciously.
Fools throw away the unoptimised Java versions of a method they re-implement in assembler, or they keep it and fail to keep it up to date. It never occurs to them that Java version may come in very handy to port the code to new platforms or to help document the assembler code. These simple, correct, but slow implementations are also useful in testing out the faster versions to make sure they give the correct results on millions of test cases.
Fools scatter their optimised code all over. Try to put together code that needs to be tweaked for a particular platform in one class. There is then a better chance it will be reoptimised for other platforms.
Fools go for long-winded solutions. Simple, clear, terse ones are easier to understand, easier to maintain, and usually run the fastest on some other platform.
On the other hand fools go for ultra-terse solutions without regard for how long they actually take to execute. They make the unwarranted assumption that shorter source always means faster code.
Fools are totally unaware of how the various system libraries work inside. They have no idea which ones are best suited for various circumstances. When it would be equally easy to code something two different ways, they have no idea which would likely run faster, and may choose a technique orders of magnitude slower that may later need to be rewritten.
Fools rampantly go for speed totally ignoring RAM usage. To their dismay they find their programs sometimes run even slower because of swapping and more frequent and difficult garbage collection.

General Tips

The sorts of thing you can legitimately do are:

Avoid creating new objects unnecesarily. Think about how to reuse old ones, e.g. pass in a return object as a parameter rather than having a method create a brand new one.
Make sure you nullify pointers when you no longer need objects freeing them up for garbage colllection.
Make sure you don’t reinvent the wheel. Use standard library code. It will gradually be tuned by clever people to use the latest and greatest algorithms without further effort on your part, e.g. sort, Collections.
Read up on buffer tweaking.
Read up on profilers. There is no point in optimising parts of the program that are not critical.
Make sure you are not packratting.
If Swing is the problem, you might consider redoing the GUI (Graphic User Interface) in IBM (International Business Machines) ’s SWT.

A Touch of Cynicism

In the end, what counts in the marketplace is the psychological impression a program gives to its users.

You can “speed up” a program by wasting even more cycles with progress bars and animated spinners — the approach pioneered by Microsoft.

If the program behaves what appears to behave like a reluctant or lazy human, it will be perceived as slow. If a program appears industrious, it can actually be a pig and get away with it.

In GUI s, what most often counts most is some sort of rapid acknowledgement feedback not the total elapsed time of some process.

Books

recommend book⇒Code Complete : A Practical Handbook of Software Construction

by:

Steve McConnell

978-1-55615-484-3

paperback

publisher:

Microsoft Press

published:

1993-05-14

Gives lots of practical advice on optimising. He talks mostly about C with examples in Fortran, Pascal, Basic and Ada. He doesn’t talk about Java. It didn’t exist when the book was written.

Greyed out stores probably do not have the item in stock

recommend book⇒Java Performance Tuning, 2nd edition

by:

Jack Shirazi

978-0-596-00377-7

paperback

publisher:

O’Reilly

published:

2003-01-21

Recommended. O’Reilly Safari book available to read online for a fee. Includes tuning EE, JDBC, servlets and JSPs, and EJBs. Make sure you get the second edition (or later).

Greyed out stores probably do not have the item in stock

recommend book⇒Java Platform Performance: Strategies and Tactics

by:

Steve Wilson, Jeff Kesselman

978-0-201-70969-8

paperback

publisher:

Prentice Hall

published:

2000-06-10

Greyed out stores probably do not have the item in stock

recommend book⇒Enterprise Java Performance

by:

Steven L. Halter, Steven J. Munroe

978-0-13-017296-9

paperback

publisher:

Prentice Hall

published:

2000-08

Greyed out stores probably do not have the item in stock

recommend book⇒Sun Performance and Tuning: Java and the Internet (2nd Edition)

by:

Adrian Cockcroft, Richard Pettit, Sun Microsystems

978-0-13-095249-3

paperback

publisher:

Prentice Hall

published:

1998-04-17

Greyed out stores probably do not have the item in stock

recommend book⇒Java ™ Puzzlers : Traps, Pitfalls, and Corner Cases

by:

Joshua J. Bloch, Neal Gafter

978-0-321-33678-1

paperback

(born: 1961-08-28 age: 50)

publisher:

Addison-Wesley

published:

2005-07-04

A set of 95 short programs that give astonishing results. When you understand them, you understand the quirkier features of Java. Bloch wrote much of the JDK class library. He also wrote the Effective Java Programming Language Guide

Greyed out stores probably do not have the item in stock

recommend book⇒Effective Java: Second Edition

by:

Joshua J. Bloch

978-0-321-35668-0

paperback

(born: 1961-08-28 age: 50)

B000WJOUPA

kindle

publisher:

Prentice Hall

published:

2008-05-28

No design patterns, just generic advice on good Java programming style. This is considered the best explanation of generics, even though it has just one chapter on generics. People claim it all came clear after reading his explanation. Not to be confused with his eariler Effective Java Programming Language Guide. book website

Greyed out stores probably do not have the item in stock

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/jgloss/optimising.html	J:\mindprod\jgloss\optimising.html
	Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : If you want your message kept confidential, not considered for posting, please explicitly specify that.
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.179.210]
Feedback	You are visitor number 13,669.