Java Glossary : optimising
Last updated 2004-06-28 by Roedy
Green ©1996-2004 Canadian Mind Products
Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
You are here : home : Java
Glossary : O words : optimising.
- optimising
- Optimising 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 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 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:
-
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 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.
-
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 in IBM's SWT.
Learning More
 | Code Complete : A Practical Handbook of Software Construction |
| 1-55615-484-4 |
| 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. |
|
|
 | Java Performance Tuning |
| 0-596-00015-4 |
| Jack Shirazi |
| O'Reilly Book. Recommended. Read more about it. |
|
|
 | Java Platform Performance: Strategies and Tactics |
| 0-201-70969-4 |
| Steve Wilson, Jeff Kesselman |
|
|
|
 | Enterprise Java Performance |
| 0-13-017296-0 |
| Steven L. Halter, Steven J. Munroe |
|
|
|
 | Sun Performance and Tuning: Java and the Internet (2nd Edition) |
| 0-13-095249-4 |
| Adrian Cockcroft, Richard Pettit, Sun Microsystems |
|
|
|
