optimising : Java Glossary

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: 71)

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:

1. Don’t do it.
2. (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

1. 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.
2. Look at the bottleneck code for obvious blunders and correct them.
3. See if there is a totally different faster algorithm for accomplishing the same thing, e.g. hashMap vs linear searching a long table.
4. Clean up the bottleneck code to ship shape. This is not considered optimising, just getting it squeaky clean with no rambling.
5. 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.
6. Consider the use of a native optimising compiler such as JET.
7. If all else fails try JNI with C/ C++. Beware. JNI only saves you CPU time if you can do a substantial amount of work in C/C++ on each call to offset the high overhead of the call.
8. If even that fails try JNI with assembler.
9. 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

• 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 in IBM’s SWT.

A Touch of Cynicism

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 GUIs, 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
		paperback
	ISBN13:	978-1-55615-484-3
	publisher:	Microsoft Press
	published:	1993-05-14
	by:	Steve McConnell
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.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Java Performance Tuning, 2nd edition
		paperback
	ISBN13:	978-0-596-00377-7
	publisher:	O’Reilly
	published:	2003-01
	by:	Jack Shirazi
Recommended. O’Reilly Safari book available to read online for a fee. Includes tuning EE, JDBC, servlets and JSPs, and EJBs. Read more about it. Make sure you get the second edition (or later).
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz o’reilly safari

	recommend book⇒Java Platform Performance: Strategies and Tactics
		paperback
	ISBN13:	978-0-201-70969-8
	publisher:	Prentice Hall
	published:	2000-06-10
	by:	Steve Wilson, Jeff Kesselman
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Enterprise Java Performance
		paperback
	ISBN13:	978-0-13-017296-9
	publisher:	Prentice Hall
	published:	2000-08
	by:	Steven L. Halter, Steven J. Munroe
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Sun Performance and Tuning: Java and the Internet (2nd Edition)
		paperback
	ISBN13:	978-0-13-095249-3
	publisher:	Prentice Hall
	published:	1998-04-17
	by:	Adrian Cockcroft, Richard Pettit, Sun Microsystems
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Java ™ Puzzlers : Traps, Pitfalls, and Corner Cases
		paperback
	ISBN13:	978-0-321-33678-1
	publisher:	Addison-Wesley
	published:	2005-07-04
	by:	Joshua Bloch, Neal Gafter
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
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Effective Java: Second Edition
		paperback	kindle
	ISBN13:	978-0-321-35668-0	B000WJOUPA
	publisher:	Prentice Hall
	published:	2008-05-28
	by:	Joshua Bloch
No design patterns, just generic advice on good Java programming style.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz