Hey Tim, On Wed, Apr 7, 2010 at 2:51 PM, Tim <[email protected]> wrote: > 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.
Primarily used to represent a Java program in an instruction set designed for efficient execution by a VM, not to represent Java source. I was pointing out that the Java language is not interpreted in the VM, is that what you are disagreeing with? > Only a pedant would say 'Android is not Java', not that that even > makes sense - Android is the OS not the VM/language. Sorry, did I do something to you to deserve the name calling? Thanks for pointing out the terminology slip, I did not mean to insinuate that. > 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 > ) It's funny, only today I was talking to a colleague about how people often use the Shootout tests and Google Trends to make their point about language performance. Please read the caveats on the Shootout test suite, particularly the comparison section: http://shootout.alioth.debian.org/flawed-benchmarks.php#comparison. As a rule of thumb, you shouldn't use the shootout suite to generalise on performance differences. All the same, I do agree that on average, C and it's derivatives out-perform Java (particularly without JIT) on a good number of benchmarks. What I don't want to do is get pulled into a low-level benchmarking argument (perhaps it's too late?) as we are talking about significant responsiveness issues on the UI, not evaluating a controlled Fibonacci test between the 2 platforms. > 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. The "stop the world" garbage collection is an interesting point to make. I've heard it before, and at the time I saw a response from Dianne Hackborn that stated that the GC of one app does not affect the functioning of another in normal handset operation. However, right now I can't find that email, so I won't argue the point :) It would be interesting to see any bugs logged for this particular GC issue. I do know that when I execute a background Service that deliberately triggers the GC regularly, that service responds slowly but my Home app continues to function properly. It is not a scientific test, but I think it makes the "stop the world" scenario more subtle than you suggest. > 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? Some of those have question marks against them, so perhaps you should say "the following are the reasons I think contribute to Android being much less responsive than the iPhone". I won't argue any of them as potential factors (most significantly, your first point does not mention "Java code", which makes it valid), but I would say that there is a lot more going on than your list above. I personally think my list is a bit more concise, but then I did write it :) > > 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!" > Couldn't agree with you more, and of course every good programmer (Java or otherwise) knows this. The problem is there are a lot of bad programmers out there, and they propagate the myth. -- 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.
