Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java Urban Performance Legends

Posted by ryuzaki0 on from the still-don't-like-java dept.

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

6 of 846 comments (clear)

  1. Nonsense by hedge_death_shootout · · Score: 5, Funny

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

  2. Java Urban Performance Legend #1 by GillBates0 · · Score: 5, Funny

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

    --
    An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
  3. First! by Anonymous Coward · · Score: 5, Funny

    First post here from my Java workstation. Take that!

  4. Maybe, there is a bit more to it, then just memory by dzafez · · Score: 3, Funny

    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);*

  5. Re:MOD THIS UP!!!!!! +9 FUNNY by wheany · · Score: 4, Funny

    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!

  6. Re:Robomaid by halleluja · · Score: 4, Funny
    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);
    }