5 ms·

Android Dalvik VM performance is a threat to the iPhone

28 points by st3fan 16y ago

amock 16y ago
This doesn't seem like a problem for Apple. Apple doesn't need more developers or faster apps. I guess that if the reason people weren't buying Android devices because of slow apps this could be a threat, but I haven't heard anyone say that slow apps were the reason for not buying an Android device.
- kylemathews 16y ago
  The 1st generation phones were (are) pretty slow. But the 2nd and 3rd generation phones are solid. Early reports from people who've gotten the new 2.2 OS have said they haven't noticed much of a speed up meaning the processor was powerful enough for most day-to-day tasks.
  - Nwallins 16y ago
    Please excuse me for noting how apologetic the tone is, says the proud owner of an HTC Hero (Sprint v2.1)
- jsz0 16y ago
  You're probably right but once you bought the device and started using it the slowness definitely contributed to the "something's not quite right" feeling you might get switching from an iPhone. The other issue it could solve,I'm not sure how widespread this is, happens when you hit the back button and nothing happens so you hit it again which registers two back presses and often dumps you back to the home screen because you hit back enough times to exit the app. I have an ancient 6 month old Android phone and this happens to me at least a few times a day.
- mechanical_fish 16y ago
  This is true, and yet you're still conceding way too much. The OP hasn't even shown a real-world benchmark, let alone pointed out a difference that a customer would care about. He's deep in the premature-optimization weeds.
dolinsky 16y ago
The fragmentation of the Android market (dot releases / hardware specs), the lack of a consistent UI and a less organized marketplace are far more of a threat to Android than any future speed disadvantage is to Apple.
- eavc 16y ago
  Lack of consistent UI? Android phones have 4 buttons that are universal across phones and across applications. If anything, it has a more consistent UI for that reason.
  - pkulak 16y ago
    Sure, but the library support makes you do a lot more yourself in Android, which means everyone coming up with their own custom solution.
    - vetinari 16y ago
      Care to elaborate? Even if a vendor uses custom skin, it does not mean that applications are inconsistent. You have to actively work around to look and behave out of place.
  - wzdd 16y ago
    I have seen this comment come up a few times, and it seemed convincing -- you would think that a specific "menu" button and a specific "back" button would mean that Android apps would at least be consistent in these two areas. But it doesn't seem to be the case. Some apps have half their settings in a "main menu" which is activated by touch and hang the rest of the "menu" button. Some apps put everything in "menu". Others have multiple "menu"s depending on where you are -- K-9 mail is a good example of this, where "menu" is context-sensitive, and preferences (for example) are distributed across three different displays. This is only intuitive once you grok the app layout. Others do horrible things such as putting menu items labelled "more" in their menus. With the "back" button, there is no guarantee that pressing "back" will take you back. Sometimes it takes you to what you were previous doing, browser-style. Sometimes it takes you to an application's main screen. Sometimes it takes you to the home screen. It depends (I guess) on how the app author has organised the Activities in her app. Really, the only consistent button on Android phones is the iPhone-like "Home" button.
desigooner 16y ago
it's like comparing apples to oranges if the test hardware setup isn't similar. would like to see this test once iPhone 4G/HD is out vs. Incredible or EVO
- elblanco 16y ago
  or they could just test it this way. http://www.iphonedownloadblog.com/2010/05/07/android-running-on-iphone-3g/ http://www.iphonedownloadblog.com/2010/05/07/android-running...
sjs 16y ago
This guy should know better being an iPhone developer. > but it also has the property that method calls in Objective-C are very slow and the more code that you write in Objective-C instead of in C/C++ the slower your codebase becomes. Obj-C is not "very slow". While it's very dynamic most code is fairly static. You setup classes with methods, instantiate objects of those classes, and send them messages. Methods are cached after the first lookup and unless you are doing very dynamic things the subsequent messages find the corresponding method rather quickly. This is old stuff and you'll find it in Smalltalk, Self, and since Rubinius is based on the blue book I bet even Ruby. It's called inline caching[1]. If you need performance in a tight loop or something you drop into C, and this is encouraged. If your Obj-C code is too slow then you optimize it. In most cases this is entirely unnecessary or has been done for you at a lower level. Without some numbers you can't expect anyone to take these claims seriously. Obj-C has been around for 20+ years. That's plenty of time for optimization and even micro-optimization, by some of the best in the industry. [1] http://en.wikipedia.org/wiki/Inline_caching http://en.wikipedia.org/wiki/Inline_caching It's nice to see Dalvik perform so well, just spare us the BS speculation about performance. (I'm also not convinced that Android development is "just Java" considering how vastly different it is from more traditional Java development, but I'll leave that one alone for now.)
- KirinDave 16y ago
  Inline Caching is awesome, and Apple's ObjC runtime has some very cool stuff. Perhaps I misunderstand what inline caching is doing, but how would that end up being faster than direct invocation? The java compiler can remove all indirection entirely, without violating any language semantics. As much as specifying all those types is tedious, it does give the compiler the capacity to do that.
  - sjs 16y ago
    I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in practice. However Dalvik being faster today doesn't mean that Obj-C is suddenly not fast enough. And when it's not fast enough you can make it so. It's not as nice as it just being done automatically, the JIT is still preferable (imo). But when it comes down to Java vs. Obj-C, even with all the verbosity, I prefer Obj-C. Even at the price of typing stringByReplacingOccurrencesOfString:withString: and some (rare) manual optimization.
c00p3r 16y ago
btw, anyone tried to use clang as a system compiler for android - it probably would give another 10-15%?
- KirinDave 16y ago
  From clang's documentation: "ARM support is mostly feature-complete, but still experimental; it hasn't undergone significant testing." It'd be interesting, but I wouldn't make any large wagers just yet. Besides, most of the juice you're going to get is going to be in your JIT.
  - c00p3r 16y ago
    As far as I know iPhone dev kit is a clang-based? Am I wrong?
jemfinch 16y ago
"Update: Just so people don’t get the wrong idea, I am a rabid iPhone user and develop for the iPhone first. This blog entry is to call out a threat that Apple should take seriously." It's really sad that such a disclaimer is needed.

28 points by st3fan 16y ago

amock 16y ago

This doesn't seem like a problem for Apple. Apple doesn't need more developers or faster apps. I guess that if the reason people weren't buying Android devices because of slow apps this could be a threat, but I haven't heard anyone say that slow apps were the reason for not buying an Android device.

kylemathews 16y ago
The 1st generation phones were (are) pretty slow. But the 2nd and 3rd generation phones are solid. Early reports from people who've gotten the new 2.2 OS have said they haven't noticed much of a speed up meaning the processor was powerful enough for most day-to-day tasks.
- Nwallins 16y ago
  Please excuse me for noting how apologetic the tone is, says the proud owner of an HTC Hero (Sprint v2.1)
jsz0 16y ago
You're probably right but once you bought the device and started using it the slowness definitely contributed to the "something's not quite right" feeling you might get switching from an iPhone. The other issue it could solve,I'm not sure how widespread this is, happens when you hit the back button and nothing happens so you hit it again which registers two back presses and often dumps you back to the home screen because you hit back enough times to exit the app. I have an ancient 6 month old Android phone and this happens to me at least a few times a day.
mechanical_fish 16y ago
This is true, and yet you're still conceding way too much. The OP hasn't even shown a real-world benchmark, let alone pointed out a difference that a customer would care about. He's deep in the premature-optimization weeds.

dolinsky 16y ago

The fragmentation of the Android market (dot releases / hardware specs), the lack of a consistent UI and a less organized marketplace are far more of a threat to Android than any future speed disadvantage is to Apple.

eavc 16y ago
Lack of consistent UI? Android phones have 4 buttons that are universal across phones and across applications. If anything, it has a more consistent UI for that reason.
- pkulak 16y ago
  Sure, but the library support makes you do a lot more yourself in Android, which means everyone coming up with their own custom solution.
  - vetinari 16y ago
    Care to elaborate? Even if a vendor uses custom skin, it does not mean that applications are inconsistent. You have to actively work around to look and behave out of place.
- wzdd 16y ago
  I have seen this comment come up a few times, and it seemed convincing -- you would think that a specific "menu" button and a specific "back" button would mean that Android apps would at least be consistent in these two areas. But it doesn't seem to be the case. Some apps have half their settings in a "main menu" which is activated by touch and hang the rest of the "menu" button. Some apps put everything in "menu". Others have multiple "menu"s depending on where you are -- K-9 mail is a good example of this, where "menu" is context-sensitive, and preferences (for example) are distributed across three different displays. This is only intuitive once you grok the app layout. Others do horrible things such as putting menu items labelled "more" in their menus. With the "back" button, there is no guarantee that pressing "back" will take you back. Sometimes it takes you to what you were previous doing, browser-style. Sometimes it takes you to an application's main screen. Sometimes it takes you to the home screen. It depends (I guess) on how the app author has organised the Activities in her app. Really, the only consistent button on Android phones is the iPhone-like "Home" button.

desigooner 16y ago

it's like comparing apples to oranges if the test hardware setup isn't similar. would like to see this test once iPhone 4G/HD is out vs. Incredible or EVO

elblanco 16y ago
or they could just test it this way. http://www.iphonedownloadblog.com/2010/05/07/android-running-on-iphone-3g/ http://www.iphonedownloadblog.com/2010/05/07/android-running...

sjs 16y ago

This guy should know better being an iPhone developer. > but it also has the property that method calls in Objective-C are very slow and the more code that you write in Objective-C instead of in C/C++ the slower your codebase becomes. Obj-C is not "very slow". While it's very dynamic most code is fairly static. You setup classes with methods, instantiate objects of those classes, and send them messages. Methods are cached after the first lookup and unless you are doing very dynamic things the subsequent messages find the corresponding method rather quickly. This is old stuff and you'll find it in Smalltalk, Self, and since Rubinius is based on the blue book I bet even Ruby. It's called inline caching[1]. If you need performance in a tight loop or something you drop into C, and this is encouraged. If your Obj-C code is too slow then you optimize it. In most cases this is entirely unnecessary or has been done for you at a lower level. Without some numbers you can't expect anyone to take these claims seriously. Obj-C has been around for 20+ years. That's plenty of time for optimization and even micro-optimization, by some of the best in the industry. [1] http://en.wikipedia.org/wiki/Inline_caching http://en.wikipedia.org/wiki/Inline_caching It's nice to see Dalvik perform so well, just spare us the BS speculation about performance. (I'm also not convinced that Android development is "just Java" considering how vastly different it is from more traditional Java development, but I'll leave that one alone for now.)

KirinDave 16y ago
Inline Caching is awesome, and Apple's ObjC runtime has some very cool stuff. Perhaps I misunderstand what inline caching is doing, but how would that end up being faster than direct invocation? The java compiler can remove all indirection entirely, without violating any language semantics. As much as specifying all those types is tedious, it does give the compiler the capacity to do that.
- sjs 16y ago
  I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in practice. However Dalvik being faster today doesn't mean that Obj-C is suddenly not fast enough. And when it's not fast enough you can make it so. It's not as nice as it just being done automatically, the JIT is still preferable (imo). But when it comes down to Java vs. Obj-C, even with all the verbosity, I prefer Obj-C. Even at the price of typing stringByReplacingOccurrencesOfString:withString: and some (rare) manual optimization.

c00p3r 16y ago

btw, anyone tried to use clang as a system compiler for android - it probably would give another 10-15%?

KirinDave 16y ago
From clang's documentation: "ARM support is mostly feature-complete, but still experimental; it hasn't undergone significant testing." It'd be interesting, but I wouldn't make any large wagers just yet. Besides, most of the juice you're going to get is going to be in your JIT.
- c00p3r 16y ago
  As far as I know iPhone dev kit is a clang-based? Am I wrong?

jemfinch 16y ago

"Update: Just so people don’t get the wrong idea, I am a rabid iPhone user and develop for the iPhone first. This blog entry is to call out a threat that Apple should take seriously." It's really sad that such a disclaimer is needed.