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."

Comments

Nonsense

[hedge_death_shootout]

These java urban performance legends are rubbish - java is highly performant in a rural or urban setting.

Re:Nonsense

[justsomebody]

And it is no urban legend needed to tell me that Coffe wakes me up much faster than C++.

Java Urban Performance Legend #1

[GillBates0]

JVM memory allocation isn't "SLOW". It's just pleasantly unhurried.

Re:Counter arguments

[Anonymous Coward]

Programmer cycles are expensive.

Not if you're counting in rupees.

Re:Article somewhat ignores the fatness of the JVM

[Anonymous Coward]

...it is continuously on the verge of eating my 1.2 GB powerbook alive

Ahhh, using those good ol' 614MB DIMMs, eh?

First!

[Anonymous Coward]

First post here from my Java workstation. Take that!

Maybe, there is a bit more to it, then just memory

[dzafez]

I haven't done anything with java in the last 5 years.
*everybody.screem("w00t!");*

I can understand the discussion about memory allocation is legitimate.
*everybody.agree();*

Now, saying this would not be the case anymore, so hence java is fast now, would be false.
*everybody.status = iritated;*

Writing jevecode does make yu handle a lot of errors...
*everybody.ask("is this not good?");* ...BY HAND!! IT WILL NOT COMPILE ELSEWAY.
*some.ask("is this not good?");*

Maybe there is a loss of speed for handling all those errors as well.
*FirstHalfOfCoders.grab(stone);*

C coders don't check for every possible error.
*SecondHalfOfCoders.grab(stone);*

Maybe, sometimes, it is ok for a programmer, if from that code, there could
be errors. While on the other side you buy speed with insecurity.
*FirstHalfOfCoders.throw(stone);*
*SecondHalfOfCoders.throw(stone);*
*me.troll();*

AND BY THE WAY; I LOVE THE "GOTO" STATEMENT!
*me.run(away);*

Re:This is Not News

[Sirch]

"When you see how productive guys like him can be, it makes me wish that some people would just stay alive, and keep working, for a few hundred years more, instead of our typical mortal lifespans"

... but that would be circumventing God's garbage collector! Just as in Java, when God has no more use for you, he'll "collect" you on his own timetable.

Of course, you could always suggest someone is collected with a shotgun...

Laugh, funny etc.

Re:Robomaid

[Doc Ruby]

BZZT: Circular reference - you lose. Should've used javac.

Re:MOD THIS UP!!!!!! +9 FUNNY

[wheany]

Oh yeah! Now that you mention it, it really is funny! You see, the article talks about how Java is not as slow as is generally believed, but then the grandparent says that he posted the message using Java! That's not funny as such, but it is when you consider that it's supposedly the first post! And it's funny to think that he might have actually been the first to post the message, but since he was using Java, its slowness caused the message to be actually posted waaay late!

Too funny!

Re:Robomaid

[halleluja]

The fact is that Java programs include more intelligence about programming from the compiler and the JVM.

It is particularly sad the Visual PnP-generation of today cannot identify the merits of GOTO's and self-modifying code.

I have never had any memory leaks, just by including the following code snippet:

/* Distributed under GPL */
#include <stdlib.h>

static void* repo = malloc(100000000);

int main(int argc, char** argv)
{
/* do stuff, just increment & cast *repo when I need to utilize free memory. */
free(repo);
}

Re:good programmers

[scotch]

I fail to see how I was rude or boastful. Perhaps you are too sensitive? As an interviewer, I am receptive to criticism that will help me conduct more productive interviews.

Though we have common ground in our opinion of the XOR trick, I guess we can agree that you'll never hire me and I'll never work for you. I can live with that arrangement if you can. Just to make sure you don't accidently hire me, whenever you interview, ask the question: "Are you willing to have sex for promotions?". I will repsond: "No, but I'll put out for a better office". That way, you'll know it's me, and I'll know it's you.