Afaik the only Android device not using OpenGL hardware acceleration is the Archos 5 (which I believe does everything in software)
I'd agree we'd see a lot of benefits from a JIT compiler, but as I've indicated before Native, Interpreted, or JIT compiled code is only one aspect, algorithms and higher level implementation details tend to have a more noticeable impact on application performance from a user perspective. Al. -- * Looking for Android Apps? - Try http://andappstore.com/ * ====== Funky Android Limited is registered in England & Wales with the company number 6741909. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. On 7 Apr 2010, at 14:51, Tim wrote: > On Apr 7, 11:41 am, Sean Hodges <[email protected]> wrote: >> On Wed, Apr 7, 2010 at 11:30 AM, Nanard <[email protected]> wrote: >>> Java problem as usual... >> >> Android is not Java... It does not use the Java VM, it does not have >> JIT, how did you come to this conclusion? > > The programs are written in Java, compiled to a bytecode that is > primarily used to represent Java source, and executed on a virtual > machine that is primarily intended to execute these Java programs. > Only a pedant would say 'Android is not Java', not that that even > makes sense - Android is the OS not the VM/language. > >>> Java is a great language, but it will never be as fast as binary >>> executable.... >> >> Says who? You? Where is your proof? > > Says everyone. Google it (and remember Dalvik is currently JIT-less). > There's some debate about whether JIT'ed Java is as fast as C, but in > most cases it isn't (good microbenchmark website: > http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gpp > ) > > Either way, Dalvik doesn't have a JIT compiler so it is *much* slower > than native code. Additionally it uses a 'stop the world' garbage > collector which periodically freezes the UI for around 0.1-0.2 > seconds. That causes little hiccups. > > So the following are reasons that contribute to Android being much > less responsive than the iPhone, in order of how much I'd guess they > affect things: > > 1. Interpreted code rather than compiled. > 2. Stop-the-world garbage collector. > 3. Lack of hardware OpenGL accelleration for the UI (afaik, maybe this > has changed in the latest versions?) > 4. Background apps. > 5. Maybe the UI thread isn't given high enough priority? > > By the way, I think the whole "You have to make sure you don't > allocate too many objects, e.g. strings in loops" kind of cancels out > the "Java is great, you don't need to worry about memory management!" > > -- > You received this message because you are subscribed to the Google Groups > "Android Discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
