Speedy Android 2.2 hits with tethering, push framework, more | Hacker News Reader

Speedy Android 2.2 hits with tethering, push framework, more

arstechnica.com

25 pointsmattyb15 comments

One note: The extra speed is by definition a bogus feature. If the apps were compiled natively for the processor in the phone, they'd already be running at full-speed. So therefore I gather that until now, the Android apps were running at a fraction of what the CPU(+) can do.

If I understand correctly, iPhone apps are compiled natively (from Objective-C). So they always ran much faster than Android apps, and now they probably still run faster, but less so. Am I correct?

(+) I used to design CPUs for a living

It's not fair to compare execution speed of Android apps and iPhone apps. There's always a tradeoff between faster development time in a higher level language and getting better performance in a lower level language, which has been debated to death on the nets for years.

The fact is, the same code runs faster on Android 2.2 than it does on 2.1. That's not bogus, it's an objective measurement.

When comparing Java and Objective-C, which one is higher level and which is lower level? The fact that Java uses bytecode doesn't necessarily increase productivity.

I'd say the standout feature that puts Java at a higher level than Objective-C is garbage collection. You could also say that Objective-C is lower level becuase it's a strict superset of C. Admittedly, it's a murky distinction. Is there a good argument for why one might consider Obj-C to be the higher level language?

I'm not familiar with Objective C; is Smalltalk-style method dispatch considered more powerful than Java method dispatch?

Objective-C supports garbage collection (optionally).

Not on the iPhone. I'd trade performance for garbage collection. Memory leaks are very common.

I'd agree that Java isn't inherently better than Objective C. There are things I like and dislike about both. It's not like comparing Ruby to C. However, you do get other advantages to using Java. In Android, every app runs in it's own VM, so multi-tasking has always been a no-brainer. I guess Apple solved the sandboxing issues, but it probably wasn't easy, and I wonder what tough decisions they had to make. Plus, it's at least in theory possible to compile any language you like to Java bytecode. So, we could see Ruby or Python apps for Android at some point. That's never going to happen with Apple for about a dozen reasons, the least of which is probably Objective C.

The main reason for the speed increase is that Froyo introduces a JIT compiler. This means that the compiler will be able to examine the running code and make optimizations based on its behavior that can outperform statically-compiled native code. Especially for long-running processes (such as apps), this could make Android's Java code run faster than the iPhone's Objective-C.

I admit that I stopped following compiler research a while back, but I doubt that a JIT compiler would use run-time behavior to beat a static compiler.

Do you have any reference or link to such optimization?

Here are some optimizations that use runtime information:

http://portal.acm.org/citation.cfm?id=346037 http://portal.acm.org/citation.cfm?id=353191

Things were so much more simple before android. iPhone was undisputed champion of smart phones, the phone choice was simple. Now theres all these options! Do I really want all these new features? Am I going to miss them if I buy the new iphone? Etc, etc, etc...

Just buy a dumb $19.99 phone (or get it for free from your carrier) and free yourself from the burden of having to choose which icon to click.

Oh the price of freedom!

Yes exactly! With choice comes decisions and with every decision there is an opportunity cost. Both phones are great! It makes choosing one over the other a more difficult decision.

Reply on news.ycombinator.com