The Java Virtual Machine (JVM) executes the bytecodes in .class files to run your program. This provides a security
sandbox which keeps users safe from aberrant programs. It also provides
an important abstraction layer between your algorithm and underlying
native C implementations of lower level libraries and methods. As
a result, you can spend your time on good architecture rather than
low level optimisations and device-specific details. Although bytecode
generally does not outperform hand-optimised C code,
it takes a fraction of the effort to write good and stable Java code
which take advantage of run-time binding of objects and method calls
to give added flexibility to your architecture.
Modern languages such as Objective C, Qt, C#, JavaScript and PHP also have late binding of objects at runtime, but this feature is lacking in traditional C and C++. It allows, for example, object polymorphism at runtime to simplify design choices, which can lead to a better architecture. When considering “C is faster” discussions of performance, it is important to moderate that with “quality of the code which runs at any instant of time” and device tests to see what impact JVM and Central Processing Unit (CPU) runtime optimisations have on late binding.
Nokia Series 40 phones are typically running on a processor which executes code in an advanced 6 stage pipeline. A single core Series 40 phone can thus do several activities at once, and in practice this means that several sequential steps may all be in process at the same time. This advanced hardware support for Java runtime performance means the cost of Java runtime bindings and indirection is very often zero. The hardware pipeline and associated optimisations mean that we often have full hardware performance from more abstract algorithms which can be coded faster than native C and C++.
As a result, it can be very difficult to even intentionally trick a Nokia Series 40 phone running Java into pipeline hazard and branch prediction error situations to test the limits of performance. The most practical advice regarding this would be “don’t worry”; do your algorithm as it should be done from a good coding standpoint, and at the same time pay attention to the areas highlighted here, where by simple choices you can impact the performance positively.