Performance Tuning - Beginning J2ME: From Novice to Professional - page 330

Creating objects in a loop imposes a double penalty in terms of performance. A new
Processor is created every time through the loop; if these objects are large enough, then garbage
collection may be forced one or more times before the loop is finished. You pay a price up front
when the object is first created, then later when the object is garbage collected.
You can almost always restructure your code to avoid this problem. For example, instead
of creating a new Processor for each input, you could do something like this:
// Set up the inputs and results arrays.
Object[] inputs = new Object[1000];
int[] results = new int[1000];
// Process each input to calculate a result.
int length = inputs.length;
Processor p = new Processor();
for (int i = 0; i < length; i++) {
p.setInput(inputs[i]);
results[i] = p.calculateResult();
}
Strings and StringBuffers
String s have a special status in Java. They are the only objects for which the plus operator (+)
is overloaded. Each time you concatenate strings using the plus operator, be wary—behind the
scenes, new String and StringBuffer objects are being created for you.
String and StringBuffer share a curious relationship. When you can create and modify
a StringBuffer , the actual work is performed on an internal character array. When you create a
String from the StringBuffer , the String points to the same character array. Everything is fine
so far, right? But if you further modify the StringBuffer , it cleverly creates a new character
array, a copy of the old one. Thus, while StringBuffer is generally an efficient way to create
String s, it is not always obvious exactly when new objects are created.
The moral of the story is that every place you see string concatenation, there may be new
objects being created. If you're assembling strings inside a loop, you should think about a different
approach, possibly involving StringBuffer . Another possible optimization is to forego String
and StringBuffer entirely and just use character arrays. While this may be a fast and efficient
solution in your own code, keep in mind that many APIs require String s as parameters and
return String s from methods, so you may end up doing a lot of conversion between character
arrays and String s.
Failing Gracefully
Given the paucity of memory in a typical MIDP device, your application should be prepared for
disappointment each time it asks for memory. Each time objects are created, your code should
catch java.lang.OutOfMemoryError . It is far better for you to catch OutOfMemoryErrors than for
your host environment to catch them. You, at least, have a chance to do something reasonable—
free up some memory and try again, or fail gracefully with a politely worded message to the
user. The host environment is not likely to be so kind, and user perception of your application
will be much worse. Bear in mind that you will probably need to free up memory by discarding
large data structures before you will have enough space to create an Alert for your message to
the user.