“We should forget about small inefficiencies, say about 97% of the time: premature optimization is the root of all evil.” ~ Donald Knuth

“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.

Books

	recommend book⇒Code Complete : A Practical Handbook of Software Construction
		paperback
	ISBN10:	1-55615-484-4
	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.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

	recommend book⇒Java Performance Tuning, 2nd edition
		paperback
	ISBN10:	0-596-00377-3
	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 J2EE, JDBC, servlets and JSPs, and EJBs. Read more about it. Make sure you get the second edition (or later).
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de O’Reilly Safari amazon.co.uk

	recommend book⇒Java Platform Performance: Strategies and Tactics
		paperback
	ISBN10:	0-201-70969-4
	ISBN13:	978-0-201-70969-8
	publisher:	Prentice Hall
	published:	2000-06-10
	by:	Steve Wilson, Jeff Kesselman
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

	recommend book⇒Enterprise Java Performance
		paperback
	ISBN10:	0-13-017296-0
	ISBN13:	978-0-13-017296-9
	publisher:	Prentice Hall
	published:	2000-08
	by:	Steven L. Halter, Steven J. Munroe
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

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

	recommend book⇒Java ™ Puzzlers : Traps, Pitfalls, and Corner Cases
		paperback
	ISBN10:	0-321-33678-X
	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
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

	recommend book⇒Effective Java Programming Language Guide
		paperback
	ISBN10:	0-201-31005-8
	ISBN13:	978-0-201-31005-4
	publisher:	Prentice Hall
	published:	2001-06-15
	by:	Joshua Bloch
No design patterns, just generic advice on good Java programming style.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk