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. Trouble getting height of OverlayItem Drawable

Solved! For anyone interested: getMarker is meant to return null if
the overlay item is using the default drawable for that
itemizedoverlay. So if you get a null back from that method, measure
the height of the default one (you can store it in an instance
variable within a subclasses itemizedoverlay so you always know the
default marker drawable) and otherwise measure the height of the
returned drawable.



2. how to include a prebuilt shared lib in mydroid build

in mydroid, using

i have some prebuilt shared libs,
i try to put them in lib/armeabi/ and hope mydroid build can zip it
into APK
but it did not

i need something like LOCAL_JNI_SHARED_LIBRARIES
mydroid can make the libs in lib/armeabi
but my so are already built

there's also a LOCAL_PREBUILT_LIBS
but it seems include $(BUILTD_PREBUILT) cannot work

it seems there's another BUILD_MULTI_PREBUILT
and it uses a mapping, something like ' libtest:test.(so|jar)'
it works for JAVA libs, but seems nothing happening for native so

so i would like to know how to include a prebuilt shared lib in
(seems sdk ant build can do this, but not mydroid)



3. CPU usage & power management question

4. creating service with bluetooth activation

5. Fans Star Trek pasti berkaca-kaca

6. 2

7. Why launch is canceled in android