16

In order to decide whether it is justified to start porting an existed iOS app (written in C) to Android, I have to estimate how fast will it be, if being implemented in Java. Some concern is the fact that Java code must be translated many times (to bytecode, then to a native one using JIT). It may affect a real time property (responsiveness) negatively , right?

What about the quality of generated code? Is it somehow comparable with gcc/llvm generated code? If yes, do you have a reference to the comparison results (paper)?

psihodelia
  • 29,566
  • 35
  • 108
  • 157
  • Does your app rely on precise realtime performance? This sounds like worrying about stuff you shouldn't worry about. – Jasarien Nov 04 '11 at 14:25
  • 4
    Your question is wrong - you don't care how much slower it is, you should be asking _will it be too slow_ and the answer is probably no. There are a great deal of apps on android that have 'real-time' features and they all seem fine :) – deanWombourne Nov 04 '11 at 14:35
  • 3
    Translation to bytecode is done by compilation, so that is a cost only incurred by you, the creator of the app, not by people running the app. – Mark Rotteveel Nov 04 '11 at 14:45

6 Answers6

23

Good question. Several years ago the performance of the Sun (now Oracle) JVM would pale in comparison to native code. But things have changed.

Firstly, the VM running Android isn't your standard JVM. Its a beefed up VM rewritten by Google specifically for mobile use, where UI performance is given priority.

Secondly, a lot has happened over the past decade... a quote from this relevant article puts it nicely: Fifteen years ago, all we thought that Java needed to rule the known universe was a faster VM. We now have a much faster VM.

Finally, there's been a lot written about comparisons between iOS and Android in terms of performance. Here's a fifth link just for kicks. There's plently more out there. It comes down to several factors - what type of code you need to run, what your performance expectations are, and how much you're willing to invest to squeeze out the most bang for your buck. And if you think Dalvik is your bottleneck, you're capable of writing native C/C++ and use JNI in Android.

Community
  • 1
  • 1
Pedantic
  • 5,032
  • 2
  • 24
  • 37
  • i would not call the dialect and simplified libraries available to jni by c++ –  Dec 28 '15 at 04:13
4

You can not compare the performance in this way. Your application will run on different pieces of hardware with different performance characteristics. The differences in performance between java/objective c is most probably negligible compared to the influence of the hardware. You should analyze the bottlenecks of your application and check if the targeted hardware can support it. If it's implemented in java does not matter that much.

Arne Deutsch
  • 14,629
  • 5
  • 53
  • 72
  • 1
    a long time ago, in the 90s, they used to justify the fact that visual basic sucked, by stating that it does not matter, because most of the time is spent with database queries. –  Dec 28 '15 at 04:14
  • 1
    java is an abomination for system development, do not believe me? look at your battery lifetime or the random delays induced by garbage collection, even in art –  Dec 28 '15 at 04:14
  • java has no multiple implementation inheritance, generics are a joke (they cast and even allocate ints in heap), same about c#, both are tools for drag and drop (sunday) enterprise programmers. why did google picked it? 1. they did not know any better, they actually purchased android from a silicon valley startup & 2. they are NOT a software company, they derive revenue from adds, surveillance, gathering and selling information to whoever happens to buy it. is this good for android customers and developers, i do not think so –  Dec 28 '15 at 04:17
2

As a test I once wrote a test app that executed a sorting algorithm on a large random list.

The C version ran about 10 times faster than the same Java version.

I would suspect that you will typically see Java running about 5 times slower than the equivalent C on the same platform.

The platform it's running on will also influence the speed of course.

Raghav Sood
  • 81,899
  • 22
  • 187
  • 195
bhause
  • 123
  • 1
  • 4
1

Even though you shouldn't care about it, yes, the Java bytecode may be slightly slower. If you're totally worrying about performance then you could use the NDK, and write most of the app in C(++).

slartibartfast
  • 4,348
  • 5
  • 31
  • 46
  • It may also be slightly faster. –  Nov 04 '11 at 14:40
  • On the other hand, the java code might be faster. We have no way of knowing since we don't even know what it does. – Robin Nov 04 '11 at 14:44
  • This is paint by numbers advice. Android doesn't even run Java bytecode. You can't really know. There are too many factors for you to predict the performance given Language A and Language B. – chubbsondubs Nov 04 '11 at 15:23
  • 1
    it is 5-10 times slower and needs 2-5 times more ram and kills the battery at least 2 times faster. in case you are not sure, these are phones, not browsers or desktops... –  Dec 28 '15 at 04:23
1

Decision whether to port to another platform usually comes from business side, not engineering. As for speed - it depends. Meanwhile JIT tends to be really fast, and it uses some optimisations at the runtime, which are not available to C compiled programs.

Nevertheless, it is impossible to predict what performance penaltiues or advantages could arise from porting without knowing what your program does.

And there is option to go with native C code which is accessed from android application - its perfromance would depend on hardware and be predictable.

Konstantin Pribluda
  • 12,329
  • 1
  • 30
  • 35
  • it comes from parasites who tell engineers what to do, killing any kind of innovation then sell them by doing all money laundry. this is how it works on this planet for thousands of years. obviously, it will not last this time for much longer. –  Dec 28 '15 at 04:19
1

Android Java isn't exactly interpreted as you think. In fact Java bytecode doesn't even make it to the device because the dalvik VM (android's JVM) doesn't interpret Java bytecode it runs DEX bytecode which is closer to the native processor format. So it's really hard to "guess" or extrapolate what the performance difference between Objective-C and Android at an arms length just based on knowing one is Java and one is native code. Not to mention you have their OS to compare as well: Linux variant vs. Mach kernel. Then Android doesn't map programs to processes in the same manner as iOS either. Given the differences in language, OS, system mapping, and variations in underlying SDK code you really can't decide without doing a little work on your side if you're going to have performance issues or not. But, that really shouldn't even matter because if there is a demand and need for your program on Android the market forces should be way more compelling than performance issues. You know the old saying "If it's really important to you, you'll find a way. If not you'll find an excuse."

chubbsondubs
  • 37,646
  • 24
  • 106
  • 138
  • even already / pre git-ed as in art, the stack machine code is slow and un-necessary memory hungry. having to box (allocate basic data types in heap for the sake of so called collections) is an abomination of desolation –  Dec 28 '15 at 04:22