Performance comparison NDK vs SDK

by MrChaz » Tue, 06 Apr 2010 21:24:40 GMT

Sponsored Links
 Does anyone have any numbers showing the difference in performance
between the NDK and SDK?

I'm curious how much difference it makes in terms of fps / number or
polys on the screen that kind of thing


Performance comparison NDK vs SDK

by Disconnect » Tue, 06 Apr 2010 21:59:22 GMT

 NDK has no way to write to the screen, so it gets zero fps. ISTR the droid
(or is it nexus?) is limited to something like 25 fps because of the
hardware design. So the SDK is 25fps faster, or [image: \infty] percent. :)


Sponsored Links

Performance comparison NDK vs SDK

by Mark Murphy » Tue, 06 Apr 2010 22:08:21 GMT

 > NDK has no way to write to the screen, so it gets zero fps.

Actually, the NDK has access to OpenGL, though I don't know the details.

Mark Murphy (a Commons Guy) 
Android App Developer Books: 


Performance comparison NDK vs SDK

by Disconnect » Tue, 06 Apr 2010 22:18:23 GMT

 Ah, yah so I see. Nice.


Performance comparison NDK vs SDK

by Ralf Schneider » Tue, 06 Apr 2010 22:37:50 GMT

 You will probably not get a clear anwser from anyone. The questions is far
more complex than it looks like.

It is no problem to put the same number of polys out in OpenGL be it with
the NDK or SDK. After all it's just same OpenGL calls. The time to render
the polys (in a batch) exeeds the time of the function call overhead by
orders of magnitude. So it is usually completely neglectable.

But as soon as an application gets more complex and performs some serious
calculations(AI, Scene Graph Management, Culling, Image processing, Number
crunching, etc.) the native version will usually be much faster.

And there is another thing: Beside the fundamental problem that there
currently is no JIT Compilation.
The current dalvikvm with its compiler seems to be very basic, without doing
any optimizations - even not the most basic ones!

There is this (very good) video: Google I/O 2009 - Writing Real-Time Games
for Android <> ;
After I have seen it, it was clear for me I will definitely use C++ with the

For example: He is talking about the overhead of function calls "Don't use
function calls".
... So yeah we are back - before 1970 and start talking about the cost of
structured programming and the performance advantage of using only global
vars and gotos.

The garbage collection is a real problem for games. So you will spend a lot
of your time thinking how you can avoid it. Even formatting a string will
create new objects. So there are tips like: don't show the FPS!
Seriously, if you know C++ it is probably easier to manage you memory with
new and delete than to tweak your architecture to reduce/avoid garbage

It seems like if you want to program a non trivial real time game, you are
loosing all the advantages of Java. Don't use Getters and Setters, Don't use
function calls. Avoid any Abstraction, etc. SERIOUSLY?

But back to your question: The performance advantage of NDK vs SDK can be
anything from 0-10000%. It all depends.

2010/4/6 MrChaz <>


Performance comparison NDK vs SDK

by MrChaz » Wed, 07 Apr 2010 05:08:33 GMT

 I was hoping that someone had tried a little test app with a simple
scene.  I think I've pretty much reached the limits in terms of get
sprites on the screen at an acceptable frame rate (at least on G1 type
It seems, at least for what I'm doing, the limit is about 100 sprites
but for my next project I'd like a bit more.
Maybe I'll just stop making games for 'old' hardware and concentrate
on the Droid and N1.  I can't say I like the idea of ignoring half the
market :(

> >

Performance comparison NDK vs SDK

by Ralf Schneider » Wed, 07 Apr 2010 05:29:08 GMT

 If your performance problem is only related to putting sprites on the
screen, don't expect an improvement by witching to the NDK.

I don't know how you are currently doint it, but these are some general

Use OpenGL ES to draw the sprites.
Limit your textures to 256x256. 512x512 seems to be slower on some devices.
Use texture atlases for smaller sprites -> To avoid state changes in OpenGL
Use VBOs
Avoid textures with alpha channels on slower devices.
Don't scale or rotate your sprites on slower devices. Slower devices often
have a fast path for simple blitt operations. => Check if "point sprites"
are available on the device. If yes, use them.
Use 16 Bit (565) textures.
Watch the video I have posted in the previous post. The speaker has some
valuable tips for performance improvements.

Anyway, 100 Sprites is not very much if you are already using OpenGL...
So may be you are right and the only solution is to target high end devices
for your next project.

2010/4/6 MrChaz <>


Performance comparison NDK vs SDK

by MrChaz » Wed, 07 Apr 2010 23:52:32 GMT

 100 is a low estimate but it's around that point that the frame-rate
seems to get into the sub 30's.
I'm already doing pretty much everything you've mentioned except using
VBOs - most sprites are rendered via the draw_texture extension.
Unfortunately pretty much all the sprites have some transparency so
I'm using ARGB_8888 for the texture atlas's.


Performance comparison NDK vs SDK

by Ralf Schneider » Thu, 08 Apr 2010 00:26:18 GMT

 There exists 4444 (GL_UNSIGNED_SHORT_4_4_4_4) Textures.
May be this helps a litle bit.

I'm not sure but switching to VBOs might not bring an improvement.
My observation on a Nexus One is: VBOs are great if there are many tris
(>250) to render per call. For billboards it really doesn't matter that
But I don't have any hard numbers this is just an observation on a specific

Many have observed most devices are currently fill-rate-limited. So, if you
have lots of overdraw it might be worth checking if you can reduce it.

2010/4/7 MrChaz <>


Performance comparison NDK vs SDK

by Menion » Thu, 08 Apr 2010 13:47:58 GMT

 I'm doing some little research school project, together with learning
basics of C++ (thanks to JNI) and here is some simple example ...

Java function:
public double doClickAction04J() {
  double x = 45.0 / (180.0 / Math.PI);
  double result = 0.5;
  for (int i = 0; i < 1000000; i++) {
    result += Math.pow(Math.cos(x), 2.0);
    result -= Math.pow(Math.sin(x), 2.0);
    result = Math.log(result);
    result = Math.exp(result);
  return result;

and C code
  (JNIEnv *env, jclass thiz) {
        double x = 45.0 / (180.0 / M_PI);
        double result = 0.5;
        int i;
        for (i = 0; i < 1000000; i++) {
                result += pow(cos(x), 2.0);
                result -= pow(sin(x), 2.0);
                result = log(result);
                result = exp(result);
    return result;

and the results?
Java: 5250ms
C :   1600ms

I then enabled experimental version of JIT compilator (in 2.1-r1
system) and new results
Java: 4700ms
C :   1600ms

so ... these are facts. I'm not really experienced with C, but this
seems for me as very objective test.


Performance comparison NDK vs SDK

by Ralf Schneider » Thu, 08 Apr 2010 15:16:56 GMT

 ou are benchmarking some math functions.

If you compile the C Code with the default setting from the NDK all floating
point operations are emulated.
The Java version executed on the Dalvik VM will hopefully use real floating
point instructions - if the CPU supports it.

So, as all benchmarks this isolated one has very little value.

Try some integer functions instead of doubles. The C version will be a lot
faster than the Java version (I estimate 10 timers faster than Java)
Enable hardware support for floats with a compiler switch. Again the C
version will be much faster again.
Try it with 32 Bit unsigned integers. The Java version will be a lot slower,
because there are no unsigned integers in Java...

Alloc (and free) lots of memory. The Java version will win (hopefully!).


2010/4/8 Menion <>


Performance comparison NDK vs SDK

by lixin China » Wed, 14 Apr 2010 02:45:35 GMT

 Hi Schneider:
As you said avoid scale the texture. Could you tell me the solution
how to render background texture(480x320 to full screen) without


Performance comparison NDK vs SDK

by Ralf Schneider » Mon, 19 Apr 2010 04:37:36 GMT

 Pre-scale the background image to match the device resolution.
Split the background image in texture tiles like 256x256, 128x128, ....
Blitt the tiles separately.

2010/4/8 lixin China <>


Performance comparison NDK vs SDK

by Lance Nanek » Thu, 22 Apr 2010 00:26:03 GMT

 >most sprites are rendered via the draw_texture extension

For very large numbers of sprites I've found that the standard draw
arrays/elements methods are much faster than the draw_texture
extension in cases where you can arrange to draw multiple sprites per
draw call. That's impossible with the draw_texture extension.


Other Threads

1. android market merchant accounts not available in europe

Merchant accounts is limited to only a handful of countries at the
moment. That means that no one else in the world can sell their apps
until Google decides to push things forward.

I made the mistake to upload the free Lite version of our app on the
market, and now users are asking when the full (paid) version will be
available. I was wondering, what do you developers do in the case
where google checkout is not available  in your country? are there any
alternatives to sell your apps? i  believe I 'm not the only one who
has this question.


2. Coexistence of "custom adb" and original adb module

A module (connectivity-bridge) has been developed to connect the
Android device via USB (OS: Windows XP). And any applications can send
(read) data into (from) device through this module without using
original module adb.exe. My module works with devices through
AdbWinApi.dll (from Android SDK). So my module works with devices
(connected via USB) analogously to original adb.exe module. Developed
module work successfully: I can find devices, send data into found
device and read response.

But I have problem, when original adb.exe is started and forwarded
(with same ports) on device which already connected via my tool. In
this situation a many errors occurres at reading data from connected

What root cause of this problem?
How I can fix this problem?



3. Categories in a ListView?

4. clarifications regarding JNI of Media Component

5. Orientation Aware websites

6. Retrieving Records from a created Database and put it in a SPINNER

7. ANDROID FoottPrint - Urgent help