The Golden Rule Of Optimisation

Don't do it. Unless you're an expert, in which case Don't do it yet

Specifically

Start with clear and clean code. Only optimise if you find that you need to, and benchmark before and after. If there's no significant improvement, get rid of it.

Loops

Long loops are where the most significant savings tend to come from, so look there first.

There are a few tricks given below, but I strongly suggest checking whether your compiler already includes an optimiser that does this. Most modern compilers will already handle them, and in fact doing too much hand-optimising may interfere with the compiler's optimiser or the virtual machine's optimiser when running the code.

Removing same-value calculations from inside loops by assigning a variable to them outside the loop. This includes the end of loop test, so:

     for (i=0;i&lt;a*c;i++) {

        n = n + log(a); 

        m = m + log(a) + i; 

     }

becomes:


     double loga = log(a); 

     double endi = a*c; 

     for (i=0;i
        n = n + loga; 

        m = m + loga + i; 

     }

Replace constants with literals (I really really doubt any modern compiler won't do this for you)
Increment (x++) rather than add (x=x+1). Again, extremely unlikely any modern compiler won't do this for you

Exceptions

Exceptions are 'expensive' to create and manage at runtime compared to status codes. You might consider that where Exceptions are not all that exceptional, where they may happen frequently, conditions should be checked instead. For a silly example:

  while (iterator.hasNext()) {

     doSomethingWith(iterator.next());

  }

is better than 

   try {

       while true doSomethingWith(iterator.next());

   }

   catch (NoSuchElementException e) {}

for many reasons. But similarly, when using a Socket, it might be worth in some circumstances checking isConnected() rather than relying on exceptions.

Making & Clearing instances

One of the most expensive (CPU) operations is making and clearing up instances. Where there are likely to be large numbers of instances being created and then left for collection, consider using a pool, but see also PoolingIsBad.

Strings

Easy things to look for are string processing routines; remember strings are immutable, so any statement that looks like a change to a string is likely to involve intermediate creations. For example, here is code that builds up spaces for indentation:

   public String indentString(int indentIndex)

   {

       String s = "";

       while (s.length() < indentIndex * 3)

       {

           s = s + " ";

       }

       return s;

   }

This creates a very large number of temporary strings, so you might think about doing things differently, for example by using StringBuffer. But remember the golden rule above. Using StringBuffer in all circumstances just gives you nastier code, and can even prevent the optimiser from doing its bit...

Parsing primitives

Other things can become important in long tight loops. For example:


   Integer i = new Integer("12");

   j = j + i.intValue();

creates an intermediate Integer object. Use the class parse method instead:


   j = j + Integer.parseInt("12");

XML

Parsing XML documents creates huge numbers of objects. So watch for multiple translations. A web service might take an incoming document, parse it, copy it into beans, and then your application builds its own business objects out of the beans. For small control message documents this might be fine (depending on the load) but for large data messages this can kill your web server.

Collecting at the right time

You can 'encourage' the garbage collector to run, if you have 'slack' moments in your application, by calling

System.gc();

Martin's Home Site (yawn)

(Created using Dreamweaver, and very nice it is too)

Last modified - - Thursday, 29-May-2008 23:14:02 BST

Hosted by Ghoulnet