Slashdot Mirror
Java Urban Performance Legends
An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know.
:) ) they weren't. The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
Yes they are. Now. 10 years ago when Java applets were being embedded in webpages (to show rippling water below a logo
Just goes to show that even if you have a great technical product you'll still need the marketdriods. Unfortunately.
http://twitter.com/onion2k
These articles keep popping up flatly stating that Java's slowness is a myth. But, no matter how many times you say it is a myth and how hard you try to create a new perception, the FACT is that people's real-world experience, no matter how anecdotal, consistently demonstrates that Java is MASSIVELY slow than similar apps in C or C++.
Java is slower. Don't even get me started on C#.
You so called counter argument is 6 years old... a lot of it weren't true to begin with, and a lot of things have happened since then.
In the end though, the MOST important thing is that these days, processor cycles are cheap. Programmer cycles are expensive. Therefore it makes sense to sacrifice a little bit of program performance to get more productive programmers.
Being bitter is drinking poison and hoping someone else will die
If you spend alot of time using stuff like valgrind and searching for memory leaks, then you are doing something very wrong. Its really not hard to just free the memory you allocate. The fact that people can write entire operating systems in C without having these problems indicates that the problems are with people, not C.
Of course, that's why I program everything in machine language. Memory allocation in hex opcodes worked for me in 1981, it still works in 2005. Programming languages don't leak memory, programmers leak memory.
In seriousness, look at the bugzillas and changelogs of any programming project. Memory leaks abound. So the reality is that memory de/allocation programming eats quite a lot of productivity, and impedes many otherwise ready releases. Of course we can de/allocate memory properly in C. And we can compute with scientific calculators. When we've got something better, we use it.
--
make install -not war
1. Make it work.
2. Make it work well.
3. Make it work fast
And #3 is the most interesting... how fast is fast? In an absolute sense, sure, C/C++ will always be faster. But does the end user notice this in a webapp? NO!
I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it. As a webapp, java on an old machine is plenty fast.
Java as a desktop GUI is an altogether different story, but I'm not using java on the desktop. This point is moot to me.
"Fast enough" to not be noticeable. That is the secret of #3. In a webapp, this is easily achieved in java.
Then use Delphi, or better yet, C#. (or even Python and a few other choices)
Faster productivity, less bugs, no ram guzzling 5 minute startup. Java isn't the only language that reduces development time, it's just the only one (besides VB) that makes you sacrifice big things to get it.
Also, let us not forget that java has memory leaks too and in my opinion they are much less obvious than C++ memory leaks.
And the command qualifiers claim the same thing in a ps view of the system, but the memory consumed rises towards 1GB. This is not unusual where Java is concerned. I have run JVMs for years and never found one willing to live within its bounds.
A *good* C++ programmer will probably write code that outperforms the equivalent in Java. A *good* C+ programmer will remember to deallocate all of his objects to prevent memory leaks. A *good* C++ programmer will copy his strings correctly to prevent buffer overflow exploits.
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by. When you add the real world to the picture you find that simple things like garbage collection and a virtual machine can make a mediocre java programmer outperform a mediocre C++ programmer.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Valid point... for 1999. But Java has been through a lot of changes since "the original JBuilder" came out. There have been three major changes to the class libraries (1.2, 1.4, and the 5.0).
Honestly, I understand why people are down on Java -- it's because there have always been two strengths to the Java "platform":
That said, I think you hit the nail ont the head -- people are still thinking in terms of 1999 and not 2005 when they think of Java -- at least on Slashdot. But the typical Java developer is busy writing enterprise apps, not writing kernel code, device drivers, or anything else that requires C/C++.
You're right, Java does have memory leaks, in a sense, but these same problems can arise in any language. You could have a cache implemented in C/C++ that is never properly emptied, so over time it fills up. Or you could have a request log where, due to a bug, requests are not always removed from the log after they are processed. Sure, you might have included code to free the objects in the cache or log when you are done with them, but the programming error is that you forgot to remove the item. This is not a language issue, this is just a programming mistake.
At least in Java you only need to worry about one problem: removing items from caches, logs, queues, etc when you are done with them; in C++ you have to also worry about de-allocating that object, which requires strict planning since the object must not be referred to anywhere else when you de-allocate it. In general you can't prove that the object isn't still referred-to by someone who had it before it was put into the cache/log/whatever; instead you need to establish rules and write documents to make sure everyone knows what the lifecycle of an object should be.
As for your company not having a memory bug logged in 3.7 years, that's great, but without knowing what kind of applications you write, or how they're used, it's hard to say if that's significant. Some programs, like, say, grep, or mv or ls or any one-time-use utilities may be rife with memory leaks, but who cares? When the program terminates the memory is freed, and the user will likely not notice the leak. But even if your apps are long-running network services or whatever, I bet the time spent by developers preventing memory leaks is significant, even if that time is completely spread out throughout the development cycle instead of in large, easy-to-spot chunks running Valgrind or some other profiler.
Simply put there may be fast efficient tiny java programs out there but I don't see them. I don't really care about how garbage is collected. All I care is that a simple editor gobbles up memory like it was some kind of FPS. Sure I love the fact that I can use the same editor with the same extensions (to a point) on my home linux machines and work evil OS machines BUT it comes at a price and that is a lot of memory.
Perhaps Sun has indeed improved java massivly over those horribly slow and crashing java applets we had a few years ago that were so going to take over the net by storm. Perhaps all the problems are just due to certain public java programs being badly written.
It doesn't matter, java is slow, c is fast. Instead of having written this article perhaps the author should have examined some common java memory hog programs and analyzed wether the fault lies with java OR the coding in question OR and this is an option few consider, that JAVA apps and C apps are often compared like apple and oranges. Azureus vs Bittorrent (a tiny and far simpler app) Eclipse vs VI etc etc.
A lot of languages deal with mis-reprensatation. I don't exactly feel sorry for the bad rep that java has as many java fanboys happily spread un-truths themselves. Like java vs PHP vs ASP for web development. Judging from my own experiences all this is just one giant "Your mom is so fat ...." competition.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I think automatic garbage collection is great, but _my_ problems with Java's memory allocator have little to do with performance. Rather, it sucks so hard at dealing with out-of-memory conditions.
Why would you ever run out of memory? If you're on a microcomputer, you tend to have an arbitrary limit anyway. The JDK default is 64MB max heap. This is to prevent runaways, but setting the heap size to some arbitrarily high number has really awful performance characteristics -- god help you if you set the number higher than the amount of RAM you have available, or applications that want to share the machine. There's a whole other rant about how stupid automatic garbage collection is on a timeshared environment (like a server), but it's not the point I want to make.
The point I want to make: since Java is supposed to run everywhere, you really can find environments where you only have 1 or 2MB of heap to play with. Having constrained resources is nothing new to programmers, they've been dealing with it forever. But Java's allocator combined with constrained resources leaves you with very little wiggle room.
If you've ever developed a Java applicatoin that manages an in-core cache you might have experienced how fucked you are when you get around to the logic of cache expiration. Ideally you can keep cache forever, as long as a) you know it's not stale, and b) you don't need the memory for something better. A is not a problem in Java, but setting up a system to facilitate B is actually really hard. In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible. When you run out of memory the garbage collector is tripped, and if it can't free anything up it generates an OOM exception. You can't realistically catch these exceptions -- they can bubble up from anywhere at any time. The only place you can catch them is at the top of your program loop and the only good it does there is let you say "OUT OF MEMORY" in a user friendly way before exiting the application -- assuming you have the resources left to even say that of course.
So how does this effect your cache model? Well, you end up having to guess at how much cache to maintain. Guess too high and your application breaks when it's run in a low memory environment. Guess too low and you're not caching enough, the user experience suffers when it has no reason to. The above scenario is just one example.
Essentially, the problem is one of prioritized memory. Java gives you no usable way of saying memory allocated for purpose X is fine as long as purpose Y is not short. Designers and apologists can make excuses for why Java doesn't support this and maybe provide a good reason, but those reasons hardly qualify Java as a general purpose programming language.
Goto also.
C# and VB.NET are almost identical in features. What do you "sacrifice" that is really important? The .NET framework is still there. C# is just java like syntax for .NET. Its not 100% better as its billed by microsoft and consultants. I agree vb6 sucked.
.NET app startup time is slower than running a program written in another language as well. Try running the ati control panel (.net version). Now that is slow. Limewire loads faster and its a java app.
The java vm startup time is a problem for client apps, but server side its not a big deal. Running tomcat with servlets, jsp and the like is very fast.
MidnightBSD: The BSD for Everyone
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
I am trolling
If you are hiring programmers who can't understand simple memory allocation and deallocation, you are more likely to run into a maintenance nightmare.
Good programmers know how to write structured code that's easy to maintain, and a side effect of this is that memory allocation becomes second nature (like most other "problem": buffer overruns, memory leaks, etc). When you write good code, these problems rarely exist. The code structure sees to it.
Just because Java tries to save you from one issue doesn't mean you can throw programmers with fewer skills at it and get the same result. Quality will suffer, because there are sill plenty of mistakes to be made in Java, and they all cost your bottom line just as much.
Please forward me the resumes of these programmers, which include "Skills" like "I never write memory leaks". And whose "Certifications" include "Good Programmer", not those other resumes which say "Bad Programmer".
The fact is that Java programs include more intelligence about programming from the compiler and the JVM. So programmers are more productive than with C. Which means that the same programmer budget can produce more product, or a lower budget can produce the same product. With distributed teams, outsourcing, OSS integration projects, those considerations are crucial to project success. Sure, quality projects also require good design and management. But Java eliminates some quality problems right out of the box. That can't be dismissed merely by saying "hire good programmers, not bad". Because it's a continuum, with a sliding scale of costs that isn't always proportional to productivity.
--
make install -not war
Unfortunately, programs such as Azureus, which run piggishly slow on a 1.2GHz laptop do nothing to dispell these 'performance myths'.
Manually determining how much memory to give to an application was one of the things that us Mac users were more than happy to leave behind with the transition to OS X. Hell, we were more than happy to kill that "feature." Dancing on its coffin and all that. Are you seriously suggesting the world go back?
Besides, I thought the biggest examples of Java was that it was all cool and dynamic and took care of things for you. It seems fair to me to expect such a language/platform to be smart enough to figure out that it's not polite to walk to the buffet, heap three plates with a ridiculous pile of food, and go back to the table and graze on a few pieces of celery, leaving the rest of the food untouched.
Five minutes startup times is also a myth. Most small to medium size Java application I have start in under a minute. Of course the more dependencies and the larger the application the more time it will take. I suppose we could compare this to you average game, written in C/C++, which can take over two minutes before you are ready to go.
For an enterprise application, running as a server, start-up time is not really an issue. What does matter is ho well it does once it is running.
Jumpstart the tartan drive.
Garbage collection is nice. It does its job and it does that job well.
But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle.
Also, if you really want the benefit of garbage collection in C++, simply compile your program using something like the Boehm Garbage Collector.
Which is the point.
Systems programmers write systems code. There is no one size fits all. There is no silver bullet. Comparing out-of-the-box C/C++ to out-of-the-box Java is a non-starter in my opinion because I've never used out-of-the-box C/C++ for large scale performance applications. What Google did in writing custom systems software is something that cannot happen with Java and is the accepted practice for C/C++.
Java programmers write applications in a "one-size-fits-all" performance environment. Comparing Java to C/C++ is like comparing apples to oranges.
Serious C/C++ systems programmers write their own malloc and systems software.
Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.
Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.
Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.
Erlang.org: wow
You can't just compare Java allocation to:
Foo *foo = new Foo();
You also have to compare it to:
Foo foo;
Experienced C++ programmers will prefer the latter both because it is faster and because you don't have to worry about freeing it. One of the problems with a lot of the "See, Java's faster than C++!" comparisons is that they tend to translate directly from Java to C++, ignoring the things you can do in C++ but not Java (like stack allocation) that have a huge performance impact.
The cake is a pie
Except, you're wrong. You're assuming that the compiler is doing *no* optimization. So, how would a compiler treat the first "inefficient" code example? Let's take a look:
public double getDistanceFrom(Component other) {
Point otherLocation = other.getLocation();
int deltaX = otherLocation.x - location.x;
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Look at the implementation of getLocation(). It's a simple non-recursive procedure. In virtually all compilers, a simple procedure like this is going to be inlined, producing:
public double getDistanceFrom(Component other) {
Point otherLocation = new Point(other.location) ;
int deltaX = otherLocation.getX() - location.getX();
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
(Note that to the compiler, all variables are effectively public, so this would not be an access violation.)
Next, the compiler can (easily) prove (by inspection) that Point(Point) is a copying constructor. As a result, it can replace the use of new Point(other.location) with other.location so long as it proves it will not modify otherLocation, and of course, it can prove this quite easily by inspection of getDistanceFrom(). This results in:
public double getDistanceFrom(Component other) {
Point otherLocation = other.location ;
int deltaX = otherLocation.getX() - location.getX();
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Also, note that getX() and getY() are also simple non-recursive leaf procedures, so the compiler would have inlined them at the same time, so you would actually get code equivalent to this:
public double getDistanceFrom(Component other) {
Point otherLocation = other.location ;
int deltaX = otherLocation.x - location.y;
int deltaY = otherLocation.y - location.y;
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Which is now faster that your hand-written "optimization." Note in fact, that you "over-optimized" by replacing otherLocation with other.location twice. If a compiler were actually dumb enough to implement it that way, literally, it would have involved an extra (and needless) pointer dereference to get the value of other.location twice, when it already had it sitting in a register. (Fortunally, most any compiler nowadays would have caught your "optimization" and fixed it.)
In fact, the compiler wouldn't stop here. It might even rearrange the order in which it fetches x and y to avoid cache pollution and misses. Do you consider that each time you fetch a variable? Most programmers don't, and shouldn't. The moral of the story is that most programmers fail to realize how smart compilers have become. Compiler writers design optimizations with "good coding practices" such as this in mind, and the programmer will be rewarded if he or she uses them.
See, that right there is a huge chunk of the whole problem. If programmers weren't being lazy and arrogant jerks and assuming that nobody cares about how poorly designed and coded their algorithms are, or how blatently horrible their memory usage is, we would have a lot fewer problems.
I don't care that Java will get there at some point, or that it's better now. I care about whether it actually works right, and right now it does not. It does have too long a startup, most of the UI toolkits are horribly slow, it does not follow native platform UI conventions, and it is just not as nice to use a Java app as it is an equally well written native app. It does take far too memory, especially compared to other languages. Even the cross-platform nature of the code is largely a lie. Different JREs don't support the same things, and many platforms lack a JRE. There are massive differences between the various editions of Java so as to make it useless to try to write something across them. Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
However, most of all, my CPU time and RAM might be cheap, but they are abused every time I use an application written in that mindset. I have memory needlessly abused, and CPU time needlessly wasted every time I run some poorly coded program. That means that I lose time and productivity every time I run your poorly written app. That attitude pisses me off, why we should all squander our system resources so that a few lazy programmers can write some app a little faster and with less effort, rather than doing their job right.
Programmer cycles are a lot cheaper than making thousands of people upgrade their hardware. I imagine those programmer cycles are a few orders of magnitude cheaper.
Java should really be compared to the STL in C++, not to C, or a bastardized C/C++ coding mix. Ideally new/delete/malloc/free should only be used in small pieces of low level code and fully encapsulated in an object.
Much of Java code can be converted almost line for line to C++. Unlike Java, the STL can create containers of any type, including built in types, operating on them very efficiently.
const size_t size = 500000000;
std:vector<int> X(size);
for(unsigned i = 0; i < size; i++)
X[i] = random();
std::sort(X.begin(), X.end());
Compare the performance of this sort() operation to its Java equivalent. Compare the space used. Notice that at no point did we worry about having to allocate/free memory, its taken care of by the vector template. To be nice we presized the vector, but we didn't need to, we could have used X.push_back(random()) with some additional overhead from automatic resizing. Something like this matters alot in high performance application, a good example would be transforms of large sets of vectors in 3d games.
Java is just another religion like LISP used to be, the CS purists are always chasing the holy grail of coding purity without regards to programming realities, yet Java is hardly even pure, its already got more evolutionary cruft than C++ and its around 1/3rd the age of the original C which has been evolved into C++.
Rarely do I see real world Java code perform with any degree of efficiency, even when compared to Perl, let alone C++. A Java appserver is much larger and uses much more CPU time than a similarly complex one written in perl.
But from all first hand reports I've heard, Java allocation is still slow.
Kep in mind that allocation in Java also includes initialization. Arrays are zeroed, object references are nulled etc. This is a good thing in general but it sure does not make allocation any faster.
As soon as you go to a website and seed the dreaded .jsp extension, you know you're in for a wait.
All the websites that use Java are just ridiculously slow. Name one that isn't.
Could you imagine Google running Java and some JVM?
Summary: "If JVMs were smart, garbage collection would be fast."
Reality: "JVMs are mostly very stupid, and you can never be sure what JVM your users are going to use, so in the real world of deployed applications garbage collection performance--and Java performance generally--is a nightmare."
I am so tired of GC advocates talking smugly about theoretical scenarios. Who cares?. When I can run a Java app on an arbitrary JVM and not have it come to a grinding halt every once in a while as the garbage collector runs--or worse yet bring the machine to a grinding halt because the garbage collector never runs--only then will GC will be useful.
The weasel-words in the article are worthy of a PHB: "the garbage collection approach tends to deal with memory management in large batches" Translation: "I wish GC dealt with memory management in large chunks, but it doesn't, so I can't in all honesty say it does, but I can imagine a theoretical scenario where it does, so I'll talk about that theoretical scenario that I wish was real instead of what is actually real."
This is not to say that there aren't one or two decent JVMs out there that have decent GC performance. But having managed a large team that deployed a very powerful Java data analysis and visualization application, and having done work in the code myself, and having had to deal with user's real-world performance issues and having seen the incredible hoops my team had to go through to get decent performance, I can honestly say that up until last year, at least, Java was Not There with regard to GC and performance.
The most telling proof: my team did such a good job and our app was so fast that many users didn't believe it was written in Java. It was users making that judgement, not developers. Users whose only exposure to Java was as users, and whose empirical observation of the language was that it resulted in extremely slow apps. They didn't observe that it was theoretically possible to write slow apps. They observed that it was really, really easy to write slow apps, in the same way it's really easy to write apps that fall over in C++, despite the fact that theoretically you can write C++ apps that never leak or crash due to developers screwing up memory.
Every language has its strengths. Java is a good, robust language that is safe to put into the hands of junior developers to do things that would take a senior developer to do in C++. But its poor performance isn't a myth, nor is its tendency to hog system resources due to poor GC. Those are emprical facts, and this article introduces no actual data to demonstrate otherwise.
Blasphemy is a human right. Blasphemophobia kills.
I believe that, directly or indirectly, an unjustifide emphasis on execution speed is the one of the biggest causes
of the failure of software projects. The problems usually begin with the choice of
implementation languages. Programming languages should
be chosen for the ease and cost effectiveness with which they can be used accurately and reliably generate
a correct and maintainable application that satisfies the customer.
In my experience selecting a language because it is "faster" than another language
before it is even known what the speed issue is for an application is just a costly mistake.
For speed critical parts of an application an experienced C++ programmer might be a without-which.
A tool like JWrapper can be used to connect a Java application to an optimized C++ library.
Speed requirements should usually be dealt with towards
the end of the development. Most of the execution time is usually spent in a small fraction of the code.
Only that portion of the code should be optimized because optimizations can be costly to derive and implement,
costly to maintain, and more difficult to verify.
In the interest of peacefull coexistence we might all agree that:
1. Java is sometimes too slow
2. C and C++ programs sometimes have memory leaks.
3. Writing efficient, reuseable, object oriented programs in C++ can be an extremely subtle business and,
as a result, good and efficient C++ programmers are harder to find.
Nope, not compared to Python or Ruby (which yield codes rougly 5 times smaller in a quarter of the production time), not compared to Lisp for an ol'timer, not even compared to C# (by a quite small margin though, but C# has a lot of very nice feature Java doesn't have).
Writing Java is faster than writing C/C++ indeed, but not "very fast", not without any referential to compare to, because dev-time wise Java gets it's ass handed to it by much more agile languages.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Productivity may be slightly hindered by the language (how easy is it to encapsulate functionality into easy-to-use packages), but I argue that it is dominated much more by the easy-to-use packages that are used.
Java certainly helps here, but good libraries can be written in many languages. In fact, most libraries are written in C so that they can be used from many languages. A library written in C plus a small wrapper for the language-du-jour is a library usable from many languages. If you have good developers on your team, libraries will be written and re-used, and productivity will be high.
Productivity comes from writing solid libraries so that you don't have to duplicate effort. Productivity comes from understanding how technologies work before you use them, so that you can avoid bug fixes, re-architecting the product, etc.
My point is that a majority of productivity doesn't come from the language, and neither does a majority of the bug-avoidance. Java may help you in a few small ways, but if you are telling me that you'd rather have people with fewer skills just because you think Java will make up for it, you're mistaken.
I never said it was. I was just responding to the point that GC is unsuitable for hard realtime systems (which is false). It's simply another method of heap management, and can be implemented with realtime requirements in mind. I also never said that Java or any other current garbage-collected language is actually suitable for this. I'm just saying that there is nothing theoretically preventing these features from being used in realtime systems. Likely to do that we will want languages (or new features for existing languages) with more expressive means of specifying the realtime requirements in a high level way.
(I do think that there are significant advantages to having a GOOD GC system that a lot of people ignore. They are simply another type of abstraction, which can be a gain when you have no need to worry about memory management implementation issues. Why should we reinvent the wheel over and over again when we can have the language designer develop a very sophisticated means of handling this automatically? There are times (such as in realtime situations) where you may want to get at the lower-level details, and that's fine. But in 90% of software written, this is absolutely unnecessary and leads to tons of bugs which could be avoided by using a higher level language.)
I've had many professors say that Java is nowhere near as slow as it used to be, and that it was just a myth now that it is that much slower the C or another language that doesn't rely on VMs. In most applications, I guess it's actually equal enough to C to be considered as an alternative.
Have they used the same machine to compare the performance, of all the different versions, on each time they compared? Also, how fast was the machine? I have a feeling that some of the people are comparing Java using fast computers with a lot of memory. I have 3 (usuable) computers: 1 P2 350, 1 P3 900 (loaner), & 1 P4 3G. I would not even want to try to run a complex java application on the P2 & P3 machines. The P4 is fast enough where using a VM is not going to make a difference. If you want to compare a Java to C++ use a slower machine (less than a gig speed & memory) it's more realistic of what people might have at home. C/C++ will win hands down on slow machines. I might also note that this article is from IBM Developer works which continually promotes Java, and I doubt it's in the there best interests to say C++ is better.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Having it be something I have to think about is what's wrong with it. Duh. This is 21st century desktop computing we're talking about, for goodness' sake. Be a good neighbor. Start with a small memory footprint, and grow it if you need to. Just like a native app.