Question

I am trying to diagnose a performance problem for a Java application which is built on top of OSGi. The platform is an ARM5 processor running on an embedded Linux box. CPU utilization is frequently 100% with high memory consumption.

I’m on the embedded O/S side of the house, with the Java developers more skilled in Enterprise application development than Embedded. While my background also includes embedded Java, I’ve avoided OSGi for precisely this reason.

I’m looking for low-hanging fruit — what are some common design errors that might be causing excess CPU and memory consumption that I could quickly investigate to get the CPU utilization back down to something far more reasonable.

Answer 1

Here are some common design traps, hope this helps:

• The creation of threads can be very “expensive”. Do you have e.g. messaging that constantly creates new threads? Use a thread pool.

• same for objects (e.g. messages, measurements), especially heavy wrappers where only a single field inside changes. Use an object pool – it helps A LOT!

• Be very careful with strings, especially concatenation. Calling simple operations on strings (replacing, appending, copying) often involve the usage of many temporary objects “under the surface”, which has a negative effect both on memory and garbage collection. When modifications of strings are done in code which is executed very often (e.g. common methods of log helper classes, methods responsible for composing messages for sending over a protocol, etc.) then optimizations which replace the ineffective methods with implementations which don’t use temporary objects improve the performance significantly.

  • Use StringBuffer
  • Use own String parsing via String.indexOf(int) instead of StringTokenizer whenever possible
  • First char comparison via string.charAt(0) is faster than String.startsWith(str)
  • Use String’s equals method instead of equalsIgnoreCase whenever possible

• adjust the log level not to include debug messages during normal work. The simple creation of all these debug messages could slow down the system considerably. Also output to the console (even if you don’t see it) usually slows down the system – always log to the OSGi Log service instead.