What is so slow about the modern JVM?
Erm... its slowness? - Back in the 90s of the past century, at a customers site we replaced two blue closet-sized boxes proudly carrying three letters with a small pizza box running HP-UX which did all the work and cycles to spare. My workstation at that time was a SPARCstation ELC with 50MHz CPU clock and 48MB RAM. I had perl 4 patchlevel 36 on it, and later the first instance of perl5.
Today I am carrying a so-called SmartPhone with me which in terms of CPU speed and memory could replace 14 of those pizza boxes. Alas, although it runs a Linux kernel and sports a (presumably) modern JVM, opening my phone rolodex (its Java) sometimes takes about 10 times the time to be responsive compared to the rolodex application I developed on my ancient ELC with perl. That's incredibly slow. Java is, more than anything else, bloat.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
This seems like a really poor analogy, it's all anecdotal. On top of that, Android isn't really a pillar of JVM accomplishment. It's well know that it's bloated and a nightmare to work with on the dev side, which inevitably percolates up to the user experience. What kind of Java code are you looking at that's "bloated"? Java has improved tremendously in the past 5-10 years in all aspects. There are plenty of things people can bitch about but overall, it's a clean, solid platform to develop on.
Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past
| [reply] |
This seems like a really poor analogy, it's all anecdotal.
It is no analogy, and even if it's all anecdotal, it is first class experience, the sort of used to build science. What's wrong with that? The hard facts are
- my old workstation was a dime against a quarter compared to that pizza box
- my phone could replace at least 10 of them (let's round that down)
- it was 10 times as responsive as the phone
which, doing the math, means that my perl application of the old days is 250 times faster. That might be a particularity of the Android platform, and yes the dev side is a nightmare - but why?
Because of bloat. If I set up a tiny Java devel environment today (think eclipse only), I spend at least about 400MB of disk space; perl5.25.10 on my platform is 105MB, add a full-fledged vim (30MB) and you have 135 MB. I suspect that if perl was used to build eclipse, it would take only a fraction of disk space, and of exercised code, maybe a dime against a dollar.
I call bloat also not using things a platform already provides, but blowing up your own souffé. Perl took the approach to use libs and tools a platform already has, whilst Java likes to cook its own soup.
Java has improved tremendously in the past 5-10 years in all aspects. There are plenty of things people can bitch about but overall, it's a clean, solid platform to develop on.
That might well be, and I am not saying Java isn't clean and solid - but it ain't the fastest thing since sliced bread, not in learning curve, not in development time, not in code execution, and don't let us talk about memory usage and garbage collection. I've seen spikes of loads of 1000 on an e10k Sun because the garbage collector kicked in... anyways - this is now an analogy: I am using the good ol' olvwm OpenLook window manager based on xview as my debian desktop, and it nicely handles all things KDE, Gnome and whatever other desktop window manager can handle. And it does it with a memory footprint of 4MB, even being bloated, too...
BTW, if Java were implemented in forth, that would give a different picture - but only because C is also bloated in comparison to forth ;-)
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |