2 ms·

"ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.

tadfisher 11y ago
50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.
- vegabook 11y ago
  I meant to be somewhat flippant. "Sarcastic..." You have made some good points, tadfisher, especially with respect to the ARM architectures being fragmented, and the ART compiler. I take those points, and indeed, I do respect the JVM because it is an awesome piece of engineering to be giving up very little for the consistent target it provides. And let's be fair, Java and Scala are not slow languages. I have more of a philosophical problem with the JVM on the desktop and server ecosystems as these don't really need it anymore - arguably - and also, you have to admit that JVM languages still force you down an OO route which is not always very elegant. Even Clojure (apparently) needs to breathe in some ugly OO syntax if you want to touch the (admittedly huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very impressed with it (I also code in Java to the Bloomberg API - less impressed with that). I don't love the JVM as you've gathered, for purist reasons and the fact that it takes me into a slightly dull corporate sort of culture, but I know that it has advantages. Anyway fun sparring with you. good points.
- gozur88 11y ago
  It's not even 50%. It's more like 30% with the JIT compiler.

50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.

vegabook 11y ago
I meant to be somewhat flippant. "Sarcastic..." You have made some good points, tadfisher, especially with respect to the ARM architectures being fragmented, and the ART compiler. I take those points, and indeed, I do respect the JVM because it is an awesome piece of engineering to be giving up very little for the consistent target it provides. And let's be fair, Java and Scala are not slow languages. I have more of a philosophical problem with the JVM on the desktop and server ecosystems as these don't really need it anymore - arguably - and also, you have to admit that JVM languages still force you down an OO route which is not always very elegant. Even Clojure (apparently) needs to breathe in some ugly OO syntax if you want to touch the (admittedly huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very impressed with it (I also code in Java to the Bloomberg API - less impressed with that). I don't love the JVM as you've gathered, for purist reasons and the fact that it takes me into a slightly dull corporate sort of culture, but I know that it has advantages. Anyway fun sparring with you. good points.
gozur88 11y ago
It's not even 50%. It's more like 30% with the JIT compiler.