3 ms·

I still maintain that Java is not a good choice for a mobile OS. Dalvik might be the best Java VM ever in the history of personal computing, but it's still just

I still maintain that Java is not a good choice for a mobile OS. Dalvik might be the best Java VM ever in the history of personal computing, but it's still just a VM. It cannot beat native code, especially on a mobile device like the Droid. I think GCC is smart enough at producing fast, tight machine code. And then there's LLVM. Why choose Java? <BEGIN RANT> I'm sick of people going on about how programmer productivity is more important than performance. I seriously don't give a fuck about programmer productivity. I only care about the end product. You have a 600MHz processor with about 128megs of RAM on your mobile device, and you still can't make it perform well? There was a time when desktop computers were slower than that, and programmers optimized the hell out of their software to make it perform acceptably on the limited hardware. I can't believe that a company like Google can't make Android perform at least acceptably, if not blazing, fast. <END RANT> I consider performance a feature. If it's not fast, I'm not using it. This is how I choose my desktop software, and this is how I choose my mobile devices. Currently, I'm looking at some Symbian devices. Symbian might not be the best mobile OS, but it's extremely responsive even on my mum's ancient Nokia 6600. EDIT: removed offending "bring on the downvotes" comment.

look_lookatme 17y ago
I'm upvoting, but go take a deep breath. The world will not turn on you just because you like your software to be fast.
- GeneralMaximus 17y ago
  Sorry, went a bit overboard there :) Performance is something I feel strongly about. At this point, people who know me are sick of my rants on how product X is too slow.
Quarrelsome 17y ago
The problem is idiots, managed idiots. C devs read way, way, way too much into performance issues with managed environments. I'm currently running a large system on an embedded device using a managed environment and its FINE. However we have been careful about our implementation. The problem is when less "able" teams are able to use managed code to create software on an embedded device. They can be utterly careless with the resources on the device as they are commonly used to playing with desktop where you can get away with a lot. They then create something that doesn't work very well and the C hackers point and laugh and state that managed software and embedded devices is a no-no. If anything managed teams just need to appreciate the limitations of the device and be more careful when assessing what toys to use. Do that and the managed world is full of win. Update: "Idiot" is probably a bit harsh. "Naive" is probably a more apt description.
gjm11 17y ago
I largely agree with that, but downvoted you on principle because I always do that to people who play the "oooo, I'm going to get downvoted, see what a nonconformist I am" card. (Which I think lowers the signal-to-noise ratio both of HN's content and, since unfortunately it sometimes works and garners lots of upvotes, of the rating system.)
- GeneralMaximus 17y ago
  Point noted. I've edited that part out now.
  - gjm11 17y ago
    I regret that the HN software doesn't allow me to un-downvote you.
nwatson 17y ago
On Android one can switch to C++/NDK for real performance-sensitive components. Other than that most Java use is either in tracking data structures, performing simple operations on them, or else in managing/responding to systems services and events (drawing UIs, responsing to keypresses, reading/writing datastores, etc). In all the latter cases there are so many layers to what happens between initiation and final result that the userland Java code represents a small portion of the total processing time. There would be NO advantage in using C there. I can buy that game programming will push the limits because many games handle large userland models and need to display much onscreen, but for MOST APPS the biggest problems that lead to perceived sluggishness don't come from using Java but instead from lazy programming where devs assume optimal response to indeterminate-time actions and don't get the optimal case ... e.g., freezing a UI while calling a web service w/ a 30-second timeout.

look_lookatme 17y ago

I'm upvoting, but go take a deep breath. The world will not turn on you just because you like your software to be fast.

GeneralMaximus 17y ago
Sorry, went a bit overboard there :) Performance is something I feel strongly about. At this point, people who know me are sick of my rants on how product X is too slow.

Quarrelsome 17y ago

The problem is idiots, managed idiots. C devs read way, way, way too much into performance issues with managed environments. I'm currently running a large system on an embedded device using a managed environment and its FINE. However we have been careful about our implementation. The problem is when less "able" teams are able to use managed code to create software on an embedded device. They can be utterly careless with the resources on the device as they are commonly used to playing with desktop where you can get away with a lot. They then create something that doesn't work very well and the C hackers point and laugh and state that managed software and embedded devices is a no-no. If anything managed teams just need to appreciate the limitations of the device and be more careful when assessing what toys to use. Do that and the managed world is full of win. Update: "Idiot" is probably a bit harsh. "Naive" is probably a more apt description.

gjm11 17y ago

I largely agree with that, but downvoted you on principle because I always do that to people who play the "oooo, I'm going to get downvoted, see what a nonconformist I am" card. (Which I think lowers the signal-to-noise ratio both of HN's content and, since unfortunately it sometimes works and garners lots of upvotes, of the rating system.)

GeneralMaximus 17y ago
Point noted. I've edited that part out now.
- gjm11 17y ago
  I regret that the HN software doesn't allow me to un-downvote you.

nwatson 17y ago

On Android one can switch to C++/NDK for real performance-sensitive components. Other than that most Java use is either in tracking data structures, performing simple operations on them, or else in managing/responding to systems services and events (drawing UIs, responsing to keypresses, reading/writing datastores, etc). In all the latter cases there are so many layers to what happens between initiation and final result that the userland Java code represents a small portion of the total processing time. There would be NO advantage in using C there. I can buy that game programming will push the limits because many games handle large userland models and need to display much onscreen, but for MOST APPS the biggest problems that lead to perceived sluggishness don't come from using Java but instead from lazy programming where devs assume optimal response to indeterminate-time actions and don't get the optimal case ... e.g., freezing a UI while calling a web service w/ a 30-second timeout.