views:

35

answers:

2

Hi all I'm having an problem with my JNI library. The execution time of the same code changes from one phone to the other. I thought it was just because we were testing on an old phone but recently I run on htc legend and all the jni code was slow...

I run the profiler and its really a night and day difference: on some phone the jni functions take 15% to 20% as on the other phones it takes 40% and 50% for the same conditions...

anybody has an explanantion?

+1  A: 

If one of the phones use JIT (Just In Time) Compiler added in Foryo (2.2) than that one should be much faster then your older ones. Are you testing it using the same android version?

Apart from that Some devices are better in float-point math than others. Devices which does not implement an FPU will emulutae float point operations. Here you can find a nice blog post about it: http://www.badlogicgames.com/wordpress/?p=71.

There are planty of sources on how to implement a float point system using fixed point arithmetics: http://en.wikipedia.org/wiki/Fixed-point_arithmetic

Moss
JIT is not applying to JNI
Will
True, so just do not take into account the first part :D
Moss
this actually seems to be the issue I've been having. since I didn't write the C code that I'm using I'm pretty limited in what I can do, but already by switching from doubles to floats I managed to gain in speed. thanks
If you build for armv5te, you will get software floating point even if hardware FP is available. The recent versions of the NDK support generation of binaries for armv5te and armv7-a (which supports hardware FP), and the correct version for the device is installed and used.
fadden
+1  A: 

Processors are certainly not created equal; they have different feeds, speeds, caching and such. The obvious explanation is that is is the processor.

Additionally system-wide things may impact processing - if you are, say, processing an image taken by the camera using JNI, the size of the image may be device-specific.

Additionally you have to check you are measuring thread-time and wall-clock time; if look at timings relative to the parts of the code that are Java, you might be seeing a relative speed-up in the Java (e.g. JIT in Android 2.2) and not a slow-down in the JNI.

Will