Environment

We will write on MacOS, as the karmic koala is still “waking up”.
Eclipse Galileo, Android SDK 1.6r1 & NDK 1.6r1, installed and configured.
We will write on NDK 1.5, because only HTC Magic (32A) is available on hand.
This test is written with the goal of "testing" the soil, before porting the game from iPhone to Android.

Testing

The following options were taken as tests:

• Quick sort
• Shell Sort
• Flip array
• Method call
• Half division method

Why is the choice so?
The "half division method", for the equation Y = 3 * cos (2 * x-4) in the interval (-10; 10) with an accuracy of 10 ^ (- 15), was chosen,
since the device does not have a coprocessor to accelerate calculations with floating point, so it was interesting to see if the transition from Java to JNI would give a gain in work. Another thing is large amounts of data and a large number of calls to “methods”. To check recursion in a compartment with a large amount of data, quick sorting was taken; to avoid recursion, the Shell algorithm was taken. To test the performance of working specifically with data, we use an array flip.
To estimate the cost of calling JNI and Java "method", we call dummy methods 10,000 times.
For sorting, we use an int array of 10,000 elements, preformed.
The results were obtained for the simulator (2.4GHz Intel Core 2 Duo), HTC Magic (32A, 1.5, kernel 2.6.29 + bfs), as well as for iPhone3G (3.1). All test methods were written in pure C.

results

Simulator

-	QS	SS	Swap	Div2	Empty
JNI (sim)	10590	253735	699	210339	13895
JAVA (sim)	100650	4573416	7861	334483	7745
Sim%	89.48	94.45	91.11	37.12	-79.41

*% - shows how many percent faster Java JNI works

HTC Magic (32A 1.5, 2.6.29-myhero-bfs)

-	QS	SS	Swap	Div2	Empty
Jni	7469	117139	880	109197	8885
Java	63569	2902912	5959	213278	5193
%	88.25	95.96	85.23	48.8	-71.1

*% - shows how much percent faster JNI from Java works. The

time for the Android platform was filmed using the java.lang.System.nanoTime () function, for the iPhone using mach_absolute_time ().
Each test was run 30 times, the result was averaged. The first result was skipped, as it was knocked out of the general indicator, apparently due to the specifics of Java.
As can be seen from the results, NDK is very effective when working with large amounts of data, a large increase is also observed when transferring “math” to JNI, the only minus is the “price” of the call. HTC Magic
Simulator And now it's comparable to an iPhone, you should not expect miracles ...

iPhone

-	QS	SS	Swap	Div2	Empty
HTC Magic JNI	7469	117139	880	109197	8885
iPhone	33531	1310358	1820	22405	769
%	77.73	91.06	51.65	-387.38	-1055.4

*% - shows how much percent Magic from iPhone works faster

The diagram does not show the Half Division method, since it is known that the iPhone with its floating-point math acceleration coprocessor will simply defeat Magic, which we see from the results. Dummy methods have also been removed, as the iPhone compiler optimizes "such code" well.

The results just hit me. Losing only in mathematics and code optimization. I think with the release of new devices the first problem will be solved.

Test sources for iPhone and Android .
PS As soon as it is possible to install firmware 1.6 on the phone, I will conduct an OpenGL comparison.