
A performance comparison between Java and C on the Nexus 5 - fysx_
http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/
======
jeswin
I've been an Android user since my first smartphone. I've heard several times
iPhone users complain that Android equivalents of their iOS apps felt
sluggish; though they couldn't pinpoint it exactly. If these numbers are true,
it might well be true. Objective-C might not suffer from such a significant
slowdown.

I think it is one of the things Apple gets right; they know what matters. As
an outsider to the iOS/Mac ecosystem I've often felt that Apple makes trade-
offs in productivity to achieve a better experience for the end user. While
these tests aren't indicative of typical app performance (most apps aren't
doing math in a loop), an order of magnitude performance difference is enough
to show up on many apps.

I wonder if Google made a mistake by not choosing native code for Android
apps. We have heard forever about Java (and other run-times) getting close to
C in performance, but outside of specific test cases native code still runs
circles around everything else out there.

~~~
lhl
While I'm sure Dalvik contributes, Android has had many more serious issues in
terms of user responsiveness.

* Android devices have very laggy touch responsiveness in general, while this is something Apple has spent considerable effort optimizing [1]

* Only in recent revisions (Project Butter [2]) has Android made significant improvements to its general UI lag/smoothness issues. At various times, Google employees have gone into extensive descriptions of why the UI is so janky [3][4]

* Many of the default Android elements were for quite a long time, very unoptimized - this included calls w/ lots of overdraw, or lack of node recycling for lists. This forced app developers to take on the bulk of performance optimization. You can take a guess how often that is done well. [5]

Over time, Android the OS, SDK/API, tools have all improved but I believe your
second paragraph gets it right. At the end of the day, people at Apple cared a
lot about getting the first versions of iOS to feel great. No one at Google
cared enough about about it. Even today, when you compare the iPhone to the
latest Nexus devices, there's lots of hardware integration issues that will
probably never get fixed (outside of community patches).

[1] [http://venturebeat.com/2013/09/19/apples-
iphone-5-touchscree...](http://venturebeat.com/2013/09/19/apples-
iphone-5-touchscreen-is-2-5-times-faster-than-android-devices/)

[2] [http://www.androidpolice.com/2012/07/12/getting-to-know-
andr...](http://www.androidpolice.com/2012/07/12/getting-to-know-
android-4-1-part-3-project-butter-how-it-works-and-what-it-added/)

[3]
[https://plus.google.com/105051985738280261832/posts/2FXDCz8x...](https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s)

[4] [http://lazytechguys.com/news/google-dev-explains-why-
android...](http://lazytechguys.com/news/google-dev-explains-why-android-user-
interface-is-laggy-while-ios-wp7-qnx-are-fluid/)

[5] [http://www.curious-creature.org/2012/12/01/android-
performan...](http://www.curious-creature.org/2012/12/01/android-performance-
case-study/)

~~~
asveikau
> [4] [http://lazytechguys.com/news/google-dev-explains-why-
> android...](http://lazytechguys.com/news/google-dev-explains-why-android-
> user-interface-is-laggy-while-ios-wp7-qnx-are-fluid/)

Man that was a weird read. Guy spends a few months interning and all of a
sudden talks about his profound connection to the campus, the fundamental
flaws in the product architecture, but watch out! He may be biased since he
will be interning on a competing product the next summer!

Regardless of the facts of the matter this seems like a very non-authoritative
source.

~~~
magicalist
It's like no one actually reads Dianne Hackborn's post (#3 above), which was
in direct response to that guy's musings going viral when he had no idea what
he was talking about.

edit: oops, that was the post that sparked the original specious musings. I
meant this followup one:
[https://plus.google.com/105051985738280261832/posts/XAZ4CeVP...](https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC)

~~~
asveikau
What drew me to #4 was the baiting headline (Google dev explains...)

------
izacus
Well, yeah, when you start developing for Android you quickly find out that
Dalvik JIT is kinda crap and it just doesn't do inlining and hotspot
optimizations very well.

Which means that pretty much computationaly intensive tasks (e.g. image
processing, crypto, etc.) are several orders of magnitude slower than what
you're used from desktop JVM. That's especially noticable in Android's
BouncyCastle crypto implementation, where standard algorithms like PBKDF#2
derivation function can take ages (e.g. 3 seconds for 10.000 iterations on
Nexus 4). Simply just moving those algorithms to C library without any
optimizations quickly gives you orders of 100-500x speedups just from the GCC
compiler (the before mentioned OpenSSL implementation of the derivation
algorithm runs about 80-150ms for same parameters and result). So now we do
pretty much any crypto or bitmap algorithms in C and just call C library via
JNI.

Of course... most apps don't really do anything computationally expensive so C
doesn't give much benefits.

~~~
Iftheshoefits
It's not just the tasks you list which are traditionally considered
(relatively) computationally intensive, in my experience. I cringe at every
loop wondering what the performance cost will be (it's not always clear or
predictable). I'm almost at the point where I'd rather just write everything
in C++, except for what absolutely cannot be.

~~~
mdwrigh2
> I cringe at every loop wondering what the performance cost will be (it's not
> always clear or predictable).

Really? I think it's fairly easy to determine what would be expensive vs.
what's going to be relatively cheap. I'd love a counterintuitive example to
prove me wrong though.

------
Narishma
He keeps saying C but the source code he shows at the end is clearly C++, even
if the file has a .c extension.

~~~
pjmlp
Yeah, I see that confusion quite often.

~~~
takeda
It is quite annoying, especially since C++ was not a superset of C for a long
time.

Those are two different languages that just happen to have same roots.

~~~
humanrebar
Technically, you're right, but practically you don't have to give up much to
write C99 that is also valid C++11.

~~~
0x09
From my own experiences writing either language I have to disagree. C++ may be
much (much much) more featureful than C, but if you skip constructs and
behavior that aren't strictly a subset of the two you are still missing a lot
of modern C, and it's exaggerated by C11. That's not just the obvious high
level features like compound literals, designated initializers, VLAs, or
anonymous structures/unions. There are a lot of creeping nits about what is
defined and undefined in either language, a famous(ly misunderstood) example
being type-punning via union, which is allowed in C but undefined behavior in
C++.

Except for a few things C++ has imported from C like stdint and vararg macros
the truth of your statement depends strongly on how far you personally tend to
stray beyond C89 in either direction.

------
hrjet
Proguard does a lot of optimisations ahead of time and is part of the standard
workflow for Android development. It would have been a more fair comparison if
Proguard optimisations were enabled (or mentioned if already enabled).

------
sagargv
An important aspect of mobile performance that this article doesn't really go
into is memory. Its not just about CPU speed. Java performs quite close to C
when excess memory is available, but performs poorly under low memory
conditions. This is true of all GCed langs. The fact that iOS apps feel
snappier is in no small part due to better memory management (ARC).

Source: Why mobile web apps are slow - [http://sealedabstract.com/rants/why-
mobile-web-apps-are-slow...](http://sealedabstract.com/rants/why-mobile-web-
apps-are-slow/)

~~~
pkolaczk
This benchmark had nothing to do with low memory conditions. Also modern GCs
do not add really that much memory overhead. Typical manual memory allocators
bookkeeping/fragmentation have comparable overheads (~10-30%). Problems of
Java being memory intensive lie elsewhere - e.g. lack of object inlining (too
many pointers everywhere), wide-strings as default, lack of lightweight
structures (two words overhead per object), the VM itself, huge OOP libraries
(even if you need a single method you need to load a whole class into memory).
90% of memory taken up by my Java IDE is _code_.

BTW: Your link is about JS, not Java. Performance problems of JS have little
to do with GC, there are much bigger problems first.

~~~
sagargv
Modern GCs do not add much overhead when _excess_ memory is available. When
the app itself consumes a lot of memory and there is little room available,
the GC gets stressed and eats too much CPU time. The chart in the link (taken
from some paper) depicts this. The problem is the GC under low memory
conditions, not Java.

Yes, the link is about JS. But there are relevant pieces.

Quote from the article: "If you want to process camera images on Android
phones for real-time object recognition or content based Augmented Reality you
probably heard about the Camera Preview Callback memory Issue. Each time your
Java application gets a preview image from the system a new chunk of memory is
allocated. When this memory chunk gets freed again by the Garbage Collector
the system freezes for 100ms-200ms. This is especially bad if the system is
under heavy load (I do object recognition on a phone – hooray it eats as much
CPU power as possible). If you browse through Android’s 1.6 source code you
realize that this is only because the wrapper (that protects us from the
native stuff) allocates a new byte array each time a new frame is available.
Build-in native code can, of course, avoid this issue."

------
bratao
Its very common to see people claiming that Java is faster than a native
compiled application. But my gut feeling says otherwise.

I don't know the Java internals on Windows. But someone know why applications
with graphical interfaces feels so slow ? My rough guess is that even if Java
is fast for mathematical operations, it needs to call native libraries for
drawing and this is expensive because of the isolation.

~~~
remon
This is almost certainly questionable programming rather than an issue with
Java performance in general. Java is the language most beginning programmers
start with and they'll do things like create wildly inefficient methods that
they proceed to call from the UI thread and so on. Additionally the most used
Java UI library (Swing) is not exactly known for its snappiness. The JNI
interface introduces overhead but certainly not anywhere near the sort of
overhead that should result in UI rendering issues. Long story short, sluggish
UIs are bad programming and not related to the programming language they were
created in.

~~~
GlennS
I'd add that there aren't many good reasons why UI programming should be slow
in any language on any desktop machine around today.

You can draw tens of thousands of things on the fly in a _web browser_ and
have it appear instantaneous to a human.

------
rossjudson
No source code for the test framework; can't see how the code is called. If
there are repeated calls through JNI, JNI transit time can often be a
significant factor.

How many times through the benchmark? Did the JIT get a chance to warm up?
Caliper provides a framework that can be used to properly assess performance.

There's no benchmark here without seeing a more complete picture.

~~~
geophile
Exactly. I wanted to play with the java code to try some possible
optimizations but this is difficult without a test driver.

------
nly
Take home: Dalvik still sucks and ART isn't good enough to replace C++ for
numerical computation on Android yet?

~~~
wbsun
Solution: native numeric computing library in ART?

~~~
mdwrigh2
If you're doing this kind of computation, do it either in Renderscript or C
and call into it from JNI.

------
hyp0
i'm amazed and hurt that dalvik doesn't do inlining (but if JIT will need a
few runs to get going... not unreasonable on a phone, if the app can stay
resident in memory)

for my fellow perplexed: ART is a java runtime (dalvik alt)
[https://source.android.com/devices/tech/dalvik/art.html](https://source.android.com/devices/tech/dalvik/art.html)

impressive improvement, x2 dalvik (on this one case...)

BUT for similar GHz (2.3 vs 2.6), intel is x2 to x8 times faster than ARM...

~~~
nly
> dalvik doesn't do inlining (but if JIT will need a few runs to get going...)

Is Dalvik actually a JIT these days? I thought it was just a bytecode
interpreter with a register based VM.

In any case, ART seems to be heading down the AOT path, which I think still
makes sense in a mobile setting.

~~~
Scaevolus
Dalvik has had a JIT since Android 2.2. It's quite limited relative to HotSpot
due to memory constraints.

------
justin66
Why do we often use graphs when displaying benchmark results? Because it gives
us a way of avoiding sentences like this:

 _Even the slowest native build using clang is not more than 43% slower than
the best native build using gcc._

------
lnanek2
I wonder if he is using ProGuard. He mentions having to manually inline
functions, so I think not. It is built-in to the Android build process,
nowadays, though, and can be turned on with just a property setting.

~~~
jmngomes
Still, using Proguard optimization with Dalvik is ill advised.

~~~
stusmall
Why do you say that?

~~~
jmngomes
"Dalvik performs many of its own optimizations, and some of the optimizations
performed by ProGuard are incompatible with Dalvik, so to avoid hard-to-
figure-out bugs (and because the net performance gain is usually small), the
default configuration turns off optimization."

in
[http://tools.android.com/recent/proguardimprovements](http://tools.android.com/recent/proguardimprovements)

------
eonwe
I'd like to see if there's a difference in the output and/or in the speed of
the C results without _-ffast-math_.

That option results some changes in the floating point math (see
[http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-
Options...](http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-
Options.html#index-ffast_002dmath-555)) which Java is unable to set, but which
may be okay for limited domain the DSP filter works in.

~~~
sharpneli
Actually -ffast-math is ok for vast majority of the applications, not just for
minority of limited domain apps.

Java has an absolutely horrible floating point support. See
[http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf](http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf)

Java code can thus never (in the current language spec) take advantage of
vector instructions etc. While in raw integer performance Java might come near
native code whenever you use floats Java is going to always lose.

The sad part here is that the decisions made on Java do not even save the
programmer from the evils of floating point math. They just cripple the
language.

~~~
jerven
I must say pointing to slides that comment on flaws mostly corrected in Java
1.2 with the strictfp keyword. And comments on concerns otherwise only
applicable to people who actually do numerical analysis on their code. i.e.
all those for who -ffast-math is most likely not acceptable. For those people
who actually care about numerical analysis and stability java 8 (finally)
gives them a way to do overflow safe code.

The second is that the a decent JVM i.e. not Dalvik do generate vector
instruction streams.

I actually think that java code in the next 4 years will start to be much
faster than equivalent C code, due to HSAIL and Graals potential to involve
GPUs and specialized floating point hardware in an otherwise normal program.

------
cpncrunch
This test would only be valid if it ran for at least a few seconds. If the
test just takes a fraction of a second then it doesn't give the dalvik JIT
compiler a chance to optimize the code. The author doesn't give the running
time, or show what value was used for the length parameter.

I'm pretty sure dalvik is NOT generally 17 times slower than native, and this
test may just be showing the start-up overhead.

------
kurtisnelson
This leads to the question: How soon until I can use Art as my daily driver?

~~~
DCKing
I've been using ART as my daily driver since it was released.

It took Whatsapp two weeks to issue an update that made it work with ART.
Nothing else and nothing since has posed any problem. In fact, I forgot I was
using it until I saw your post.

~~~
mmastrac
I've been doing the same with spectacular results, although it's possible that
some of the camera crashes (and maybe the IMDB crash I get from time-to-time)
are ART-related.

~~~
mscrivo
They are not. I'm still on dalvik and the camera crashes and frequently uses
100% cpu in the background.

------
higherpurpose
When is Google going to support Go in Android?

~~~
pjmlp
When they ever bother to implement this 2012 open ticket.

[https://code.google.com/p/android/issues/detail?id=39482](https://code.google.com/p/android/issues/detail?id=39482)

~~~
higherpurpose
Maybe they're doing it behind the scenes for Android 5.0, and aren't telling
us about it? Google isn't exactly doing community development of Android. One
can hope.

~~~
pjmlp
Actually from the tone of last Google IO, I thought they might use Dart, given
some hints about "upcoming stuff", which never materialized.

The original Android team had a few ex-Sun employees from the Java team, so it
might also play a role there. Just guessing.

------
puppetmaster3
As a developer, Andorid is like EJB, very badly designed for threads
android.widget.BaseAdapter with panes and . Even Swing is better.

IOS has these nice loops, more like HMTL.

I hope Google copies Firefox mobile via Gentoo based ChromeOS. Their copying
of Java took the worst parts.

'Andorid is the new IE'

------
raverbashing
And this is one of the reasons the iPhone feels more responsive with the same
(or worse) hardware

Sure, Dalvik may have a JIT but it's difficult to do miracles with a limited
amount of memory (and the JIT needs to be fast as well)

~~~
mdwrigh2
> And this is one of the reasons the iPhone feels more responsive with the
> same (or worse) hardware

This is making the assumption that any latency delta is because the system is
CPU bound; I suspect this is one of the least likely cases. In general, I
suspect apps are going to be I/O or fillrate bound, with some additional
latency because touch controllers aren't benchmarked and are only starting to
get more love from device manufacturers.

------
sehugg
It's weird that the author chose to use field accesses (in every possible
instance) instead of local variables in the manually optimized version.

------
fsk
I thought that C on Android compiles to bytecode just like Java, rather than
being a true native binary?

~~~
jevinskie
Nope, the NDK uses the same GCC and Clang that you are familiar with (plus
some patches).

------
userbinator
It's interesting to see the saying "Java: compile once, run (slowly)
everywhere", which has been around for about as long as Java has, still
applies after all these years despite claims that somehow "better technology"
in compilers will make the efficiency gap disappear.

You don't have to be a computer scientist to see that the fastest way of doing
anything is not doing it at all --- and with Java's architecture, there will
always be instructions executed which are completely unnecessary in native
code. They can make huge sacrifices in memory consumption (e.g garbage
collection that doesn't collect at all, if you have enough memory) to try to
reduce things like allocation/deallocation cost, but in the end they're still
wasting more resources.

