Talk:Java ME code optimization

From Nokia Developer Wiki
Jump to: navigation, search

Most of those are done by the compiler.

You can import whatever you want, only the statically needed will really be imported.

Divisions and multiplications are optimized by the compiler too, as well as the '+', which is replaced by the compiler by a StringBuffer.

HashMap is not an existing Java ME Class.

One can only assume that manual garbage collection is only called when actually needed, usually for memory reasons, which overcomes performance reasons.

Too much optimization is just as bad as too few, so the first question to ask is: do i have performance issuses?

And a good design with the proper algorithm is often quite optimized already.

Avoid Adding ones Name in document:

The documents on WIKI are contributions of all users, and dont belong to a single one so please dont put your name at the bottom. Your contributions get recorded in edit history of the document.



I don't quite agree with the paragraph regarding record stores : opening the recordstore in the startapp and keeping it open is the best way to corrupt data if the application is interrupted brutally.

Instead, I would recommend keeping the opening and the closing together, and to group as much as possible readings and writings in sequences

Above is logically correct and agree, added this to article, thanks !

-- vdharankar

Creating and discarding objects: be very wary about re-using objects. Objects that have been used for something else may be left in a different state to a fresh object, resulting in unexpected bugs.

Partition Your Application: when classes are loaded is at the discression of the implementation (within certain constraints). Classes are loaded as "needed". They are never unloaded, so it is hard to save memory by using more, smaller classes. Many small classes may slow down your application, because the classes will be loaded during execution rather than at start-up. That said, many small classes should be considered a best practice (though, from a software engineering perspective, not one of performance or memory optimization).

Partition Your Application: it is better only to import the classes you need. However, this has no affect on application size or performance, since imports do not generate code.

Partition Your Application: avoid public variables (or even non-local variables) as much as possible! Avoiding set/get methods might reduce size and increase performance, but can make code more liable to bugs and harder to read. The cost is rarely worth it.

Avoid Frequent opening of Recordstores: keeping record stores open for long periods of time may cause them to lose changes or become corrupt. This can occur if record stores are open when the application terminates, on some devices. I would usually recommend closing record stores as soon as possible after opening to avoid this problem. Record store performance can be enhanced by using fewer, larger records. In tests on a Nokia Series 40, reading a single record of 10,000 bytes was 80 times faster than reading 100 records of 100 bytes each (same number of bytes in total).

Reuse GUI components: re-using objects saves no memory, compared to discarding objects and creating fresh ones. See my first comment.

Use Appropriate type for variables: be vary careful about using types like byte and short, when int would do. The memory saving is minimal (there is no saving at all for local variables or parameters), code size will increase and performance will suffer. Java VMs always perform arithmetic on ints, and bytes and shorts require that conversion byte-codes be inserted into the code. Memory savings are much larger for byte[] or short[], however. Be careful to consider if the range of values might increase in the future (when porting to other devices, for example). Some people use byte for screen coordinates, forgetting that some screens are larger that 128x128.

Reuse Variables: local variables access much faster than non-locals, so non-local variables should be avoided. Re-using local variables for more than one purpose makes naming hard, and so can reduce readability. Re-use local variable slots in the stack frame by minimizing scope (declare variables inside {} blocks).

Calculations: beware that "a/2" and "a>>1" are not identical. A right-shift always rounds down, while division rounds towards zero. Hence "-3 >> 1 == -2" while "-3 / 2 == -1".


Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.