Dont you think that the big issue here is a base problem?: We are talking about a real time system (in most functions) and the current architecture dont behave accordingly. Appart from java.
On 7 abr, 17:25, Sean Hodges <[email protected]> wrote: > 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〈=jav... > > ) > > 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.
