Java performance

Discussion in 'Java' started by borophyll@gmail.com, Nov 4, 2007.

  1. Guest

    I am just interested in the latest stats on Java performance. A lot
    of the literature appears to be out of date in this respect. Is it
    true that Java performance is close to that of native compiled code?
    I suppose it could be said that Java *is* natively compiled (at run
    time), but there will surely be performance penalties due to bytecode
    translation, at least at program startup.

    Can Java be used for graphics-intensive applications, such as the
    latest 3D game, such as Doom/Quake/whatever is the current hot game.
    If not, what are the issues that prohibit Java from being suitable.

    Finally, I have read that garbage collection is generally more
    efficient than manual memory management. Is this true, and if so,
    why?

    Please feel free to mention anything else that is relevant...

    Regards,
    B.
    , Nov 4, 2007
    #1
    1. Advertising

  2. On Nov 4, 12:41 pm, wrote:
    > I am just interested in the latest stats on Java performance. A lot
    > of the literature appears to be out of date in this respect. Is it
    > true that Java performance is close to that of native compiled code?


    Yes.

    > I suppose it could be said that Java *is* natively compiled (at run
    > time), but there will surely be performance penalties due to bytecode
    > translation, at least at program startup.


    Yes, at startup.

    > Can Java be used for graphics-intensive applications, such as the
    > latest 3D game, such as Doom/Quake/whatever is the current hot game.


    Current? Well, there is e.g. a Quake 2 engine port to Java
    http://bytonic.de/html/jake2.html

    There are other game engines, too. E.g. http://www.jmonkeyengine.com/

    And there are other types of graphic intensive applications, too. CAD
    systems have been written in Java, so have GIS systems. People do
    complex simulations in Java and all kinds of computational intensive
    stuff.

    > If not, what are the issues that prohibit Java from being suitable.


    For what? Games? Game users might be used to all kinds of long startup
    times, so Java's typical long startup times might not be an issue.
    Game users are also used to be able to use a number of HID devices
    (joysticks, wheels). There is a total lack of out-of-the-box support
    in Java for such devices. There are third-party libraries to overcome
    this. There is also an almost total lack of out-of-the-box integration
    into advanced sound engines. Java-sound does not cover all details.
    There are maybe third-party libraries to fix this, I am not aware of
    any. There is at best mediocre media support (video playing, MP3
    playing). The Java media framework has been neglected for years.

    What is really bad in Java is desktop integration. Interaction with
    native installation management or package management does not exist.
    All things which are closer to the system are bad. Dealing with
    removable media in general is bad, e.g. figuring out if a CD or DVD is
    in a drive can't be done with Java alone. Dealing with all kinds of
    system services is bad. Typical desktop I/O (serial, USB, parallel
    ports, Firewire) is not or badly supported.

    There is only one compelling technical reason to do a desktop
    application in Java. When you really, really, really badly, need the
    cross-platform features of Java so your application runs on multiple
    platforms. The price you will have to pay for this is that the
    application will look and behave slightly alien on all supported
    platforms. And some things won't work at all.

    > Finally, I have read that garbage collection is generally more
    > efficient than manual memory management. Is this true, and if so,
    > why?


    It has advantages and disadvantages. You can study the details for
    ages. But in short it usually doesn't hurt and is in general "better",
    unless you mess up things.
    Hunter Gratzner, Nov 4, 2007
    #2
    1. Advertising

  3. Lew Guest

    wrote:
    >> I am just interested in the latest stats on Java performance. A lot
    >> of the literature appears to be out of date in this respect. Is it
    >> true that Java performance is close to that of native compiled code?


    Hunter Gratzner wrote:
    > Yes.


    Or faster, sometimes.

    >> Finally, I have read that garbage collection is generally more
    >> efficient than manual memory management. Is this true, and if so,
    >> why?


    > It has advantages and disadvantages. You can study the details for
    > ages. But in short it usually doesn't hurt and is in general "better",
    > unless you mess up things.


    Whereas platforms without GC require more code to handle allocation and
    deallocation, and will cause trouble if you mess up things.

    Allocation of a new object on the heap in Java is on the order of 10x fewer
    machine instructions than in C++. Deallocation of young objects, on the order
    of 95% of all objects in most programs (particularly if you're versed in Java
    idioms), is essentially zero cost.

    More importantly, GC greatly reduces the window of opportunity for
    memory-management bugs. As Hunter says, there are ways to defeat its advantages.

    Furthermore, there are multiple algorithms available. Try to duplicate the
    scalability of Sun's parallel GC algorithms in a non-GCed environment. The
    era of the single-processor computer is giving way to a multi-processor world.

    Never mind how Java's GC harmonizes with Hotspot compilation.

    -
    Lew
    Lew, Nov 4, 2007
    #3
  4. Christian Guest

    schrieb:
    > I am just interested in the latest stats on Java performance. A lot
    > of the literature appears to be out of date in this respect. Is it
    > true that Java performance is close to that of native compiled code?
    > I suppose it could be said that Java *is* natively compiled (at run
    > time), but there will surely be performance penalties due to bytecode
    > translation, at least at program startup.
    >
    > Can Java be used for graphics-intensive applications, such as the
    > latest 3D game, such as Doom/Quake/whatever is the current hot game.
    > If not, what are the issues that prohibit Java from being suitable.
    >


    I would say problematic is that for example OpenGL needs native
    librarys.. calling these via jni has an overhead that will kill your
    performance.

    The other thing which I have seen is that java may have caught up with
    performance.. though a little overhead stays .. specially if you not
    program c++ but hack c++ you can gain some bits of performance that may
    be relevant for one of the latest games to even run on a machine (like
    doing bitflipping in a pointer to traverse a list of vertices really fast).

    Java is a great language but it doesn't fit for everything. Thinking
    Java and its features like the runtime optimization will fix everything
    for you in speed that the additional security like typechecking or
    nullpointer checking costs you is I think hybris.

    > Finally, I have read that garbage collection is generally more
    > efficient than manual memory management. Is this true, and if so,
    > why?
    >
    > Please feel free to mention anything else that is relevant...
    >
    > Regards,
    > B.
    >
    Christian, Nov 4, 2007
    #4
  5. Lew Guest

    Christian wrote:
    > I would say problematic is that for example OpenGL needs native
    > librarys.. calling these via jni [sic] has an overhead that will kill your
    > performance.


    Well, maybe not "kill", but it will have an impact. The trick is to have the
    native method do enough work to make up for the overhead of the JNI barrier.

    Unfortunately, you are correct about OpenGL needing JNI.

    --
    Lew
    Lew, Nov 4, 2007
    #5
  6. Hunter Gratzner wrote:
    > On Nov 4, 12:41 pm, wrote:
    >> I am just interested in the latest stats on Java performance. A lot
    >> of the literature appears to be out of date in this respect. Is it
    >> true that Java performance is close to that of native compiled code?

    >
    > Yes.
    >
    >> I suppose it could be said that Java *is* natively compiled (at run
    >> time), but there will surely be performance penalties due to bytecode
    >> translation, at least at program startup.

    >
    > Yes, at startup.
    >
    >> Can Java be used for graphics-intensive applications, such as the
    >> latest 3D game, such as Doom/Quake/whatever is the current hot game.

    >
    > Current? Well, there is e.g. a Quake 2 engine port to Java
    > http://bytonic.de/html/jake2.html
    >
    > There are other game engines, too. E.g. http://www.jmonkeyengine.com/
    >
    > And there are other types of graphic intensive applications, too. CAD
    > systems have been written in Java, so have GIS systems. People do
    > complex simulations in Java and all kinds of computational intensive
    > stuff.
    >
    >> If not, what are the issues that prohibit Java from being suitable.

    >
    > For what? Games? Game users might be used to all kinds of long startup
    > times, so Java's typical long startup times might not be an issue.
    > Game users are also used to be able to use a number of HID devices
    > (joysticks, wheels). There is a total lack of out-of-the-box support
    > in Java for such devices. There are third-party libraries to overcome
    > this. There is also an almost total lack of out-of-the-box integration
    > into advanced sound engines. Java-sound does not cover all details.
    > There are maybe third-party libraries to fix this, I am not aware of
    > any. There is at best mediocre media support (video playing, MP3
    > playing). The Java media framework has been neglected for years.
    >
    > What is really bad in Java is desktop integration. Interaction with
    > native installation management or package management does not exist.
    > All things which are closer to the system are bad. Dealing with
    > removable media in general is bad, e.g. figuring out if a CD or DVD is
    > in a drive can't be done with Java alone. Dealing with all kinds of
    > system services is bad. Typical desktop I/O (serial, USB, parallel
    > ports, Firewire) is not or badly supported.
    >
    > There is only one compelling technical reason to do a desktop
    > application in Java. When you really, really, really badly, need the
    > cross-platform features of Java so your application runs on multiple
    > platforms. The price you will have to pay for this is that the
    > application will look and behave slightly alien on all supported
    > platforms. And some things won't work at all.
    >
    >> Finally, I have read that garbage collection is generally more
    >> efficient than manual memory management. Is this true, and if so,
    >> why?

    >
    > It has advantages and disadvantages. You can study the details for
    > ages. But in short it usually doesn't hurt and is in general "better",
    > unless you mess up things.
    >


    The coming JRE is going to have greatly improved startup performance.

    https://jdk6.dev.java.net/6uNea.html

    I've played with it a little bit on windows and there does seem to be
    some performance increase.

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Nov 4, 2007
    #6
  7. Roedy Green Guest

    On Sun, 04 Nov 2007 11:41:46 -0000, wrote, quoted
    or indirectly quoted someone who said :

    >Is it
    >true that Java performance is close to that of native compiled code?


    You have the option of native compiled code with Jet. See
    http://mindprod.com/jgloss/benchmark.html

    Jet produces BETTER code than hand assembly.

    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Nov 4, 2007
    #7
  8. Roedy Green Guest

    On Sun, 04 Nov 2007 11:41:46 -0000, wrote, quoted
    or indirectly quoted someone who said :

    >Can Java be used for graphics-intensive applications, such as the
    >latest 3D game, such as Doom/Quake/whatever is the current hot game.
    >If not, what are the issues that prohibit Java from being suitable.


    There is VolatileImage which gives you ability to rapidly bitblt
    inside the regen.

    I have not played with Java 3D.

    In the old days you poked the hardware directly with machine code. I
    presume today you have device drivers to access the clever parallel
    processing hardware in the video cards. The key would be how
    impedance matched the Java API is to the device driver API on any
    given platform. Java is always constrained my the least common
    denominator principle. In general, it can't use features of a
    platform unless all platforms support it.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Nov 4, 2007
    #8
  9. wrote:
    > I am just interested in the latest stats on Java performance. A lot
    > of the literature appears to be out of date in this respect. Is it
    > true that Java performance is close to that of native compiled code?
    > I suppose it could be said that Java *is* natively compiled (at run
    > time), but there will surely be performance penalties due to bytecode
    > translation, at least at program startup.


    In the extreme short-term (i.e., in the first few minutes), Java is
    going to have noticeable impact: one comparison metric gives it about
    1.2-1.3 times native code (after taking startup into account). Over
    longer periods of time--especially if the server VM is used--Java
    performance is near, at, or better than native compiled code.

    > Finally, I have read that garbage collection is generally more
    > efficient than manual memory management. Is this true, and if so,
    > why?


    In most cases, yes. Part of the problem is that manual management is
    manual and people are not quite as good at profiling memory as computers
    are. In addition, garbage collection can more easily benefit from
    parallel execution, a bonus in the coming days of multi-core CPUs and
    other parallelization techniques.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Nov 4, 2007
    #9
  10. Lew Guest

    Knute Johnson wrote:
    > The coming JRE is going to have greatly improved startup performance.
    >
    > https://jdk6.dev.java.net/6uNea.html
    >
    > I've played with it a little bit on windows and there does seem to be
    > some performance increase.


    If you really are talking about Java 6, it's been out already for almost a year.

    --
    Lew
    Lew, Nov 4, 2007
    #10
  11. Christian Guest

    Joshua Cranmer schrieb:
    > wrote:
    >> I am just interested in the latest stats on Java performance. A lot
    >> of the literature appears to be out of date in this respect. Is it
    >> true that Java performance is close to that of native compiled code?
    >> I suppose it could be said that Java *is* natively compiled (at run
    >> time), but there will surely be performance penalties due to bytecode
    >> translation, at least at program startup.

    >
    > In the extreme short-term (i.e., in the first few minutes), Java is
    > going to have noticeable impact: one comparison metric gives it about
    > 1.2-1.3 times native code (after taking startup into account). Over
    > longer periods of time--especially if the server VM is used--Java
    > performance is near, at, or better than native compiled code.
    >
    >> Finally, I have read that garbage collection is generally more
    >> efficient than manual memory management. Is this true, and if so,
    >> why?

    >
    > In most cases, yes. Part of the problem is that manual management is
    > manual and people are not quite as good at profiling memory as computers
    > are. In addition, garbage collection can more easily benefit from
    > parallel execution, a bonus in the coming days of multi-core CPUs and
    > other parallelization techniques.
    >


    though there seem to be other problems with compiling in java ...
    I once heard the term "hotspotless" code used for GUI parts written in
    pure java..
    meaning that java's guis have the problem that they are not hot spots
    ... as a user won't klick each button that often resulting in gui code
    not being compiled down to native code but just allways being
    interpreted which might result in an unreactive GUI as an effect (or at
    least a GUI that is less reactive than a native couterpart)
    Christian, Nov 4, 2007
    #11
  12. Roedy Green Guest

    On Sun, 04 Nov 2007 19:16:25 GMT, Joshua Cranmer
    <> wrote, quoted or indirectly quoted someone
    who said :

    >In the extreme short-term (i.e., in the first few minutes), Java is
    >going to have noticeable impact: one comparison metric gives it about
    >1.2-1.3 times native code (after taking startup into account). Over
    >longer periods of time--especially if the server VM is used--Java
    >performance is near, at, or better than native compiled code.


    On an older machine you will notice a difference the Swing GUI makes.
    It has an extra layer of overhead between the application and the
    hardware. With a 2 GHz machine you likely won't notice it. It as fast
    enough to keep up with a human.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Nov 4, 2007
    #12
  13. Christian wrote:
    > .. as a user won't klick each button that often resulting in gui code
    > not being compiled down to native code but just allways being
    > interpreted which might result in an unreactive GUI as an effect (or at
    > least a GUI that is less reactive than a native couterpart)


    I don't really understand the first part of your sentence, but I can
    deal with the last part of it:

    Unresponsive GUIs are more a symptom of poor programming skills (e.g.,
    someone's doing too much in the EDT that could be done elsewhere) than
    of native-versus-non-native code problems. I have seen native GUIs
    become unresponsive just as much--in both Windows and Linux implementations.

    In fact, from the little I know of various toolkit implementations, this
    is just as much a problem in Java Swing code as it is GTK2 or Windows API.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Nov 4, 2007
    #13
  14. Roedy Green Guest

    On Sun, 04 Nov 2007 20:32:21 +0100, Christian <> wrote,
    quoted or indirectly quoted someone who said :

    >though there seem to be other problems with compiling in java ...
    >I once heard the term "hotspotless" code used for GUI parts written in
    >pure java..
    >meaning that java's guis have the problem that they are not hot spots
    >.. as a user won't klick each button that often resulting in gui code
    >not being compiled down to native code but just allways being
    >interpreted which might result in an unreactive GUI as an effect (or at
    >least a GUI that is less reactive than a native couterpart)


    The whole point of hotspot is you don't waste the RAM for native code
    or the CPU time to optimally compile unless the method is frequently
    used.

    Sun people are primarily thinking today about server code that runs
    for days at time. What counts is how well it performs after the first
    5 minutes of running.

    The big desktop or Applet performance hit today is the time it takes
    to load the Java run time and hotspot hundreds of standard classes. I
    have suggested ever since I first encountered Java they could greatly
    speed up launch by precompiling a set of commonly used classes and
    capturing the RAM image with a process I call gespenstering I used in
    DOS Abundance to create relocatables out of raw RAM images.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Nov 4, 2007
    #14
  15. writes:

    > I am just interested in the latest stats on Java performance. A lot
    > of the literature appears to be out of date in this respect. Is it
    > true that Java performance is close to that of native compiled code?


    True in many cases, yes.

    > I suppose it could be said that Java *is* natively compiled (at run
    > time), but there will surely be performance penalties due to bytecode
    > translation, at least at program startup.


    That's one reason that Java is currently far more popular for long-running
    server applications than it is for browser applets or desktop apps. Startup
    time isn't such a big deal when the app is rarely killed and restarted.

    > Can Java be used for graphics-intensive applications, such as the
    > latest 3D game, such as Doom/Quake/whatever is the current hot game.
    > If not, what are the issues that prohibit Java from being suitable.


    I've quite a bit of experience in cross-language development (see my .sig),
    and in my experience the cost of crossing the language barrier tends to be
    pretty high. That doesn't make Java unsuitable for high-performance 3D apps,
    it just means you need to carefully think about and manage how your Java
    code calls the low-level 3D rendering functions.

    > Finally, I have read that garbage collection is generally more
    > efficient than manual memory management. Is this true, and if so,
    > why?


    It's easier than some manual schemes, and about on par with others. It's
    definitely easier than old-school malloc()/free(). But, there are "semi-
    manual" techniques such as those used in C++ (stack-based objects and STL
    collections) or Objective-C (autorelease pools and design patterns that
    support them) that are also much easier than the old-school approach.

    Sun likes to pretend that the old-school approach is the only possible
    alternative to Java, so as to make Java look better in comparison. The
    truth isn't as black-and-white as that.

    sherm--

    --
    WV News, Blogging, and Discussion: http://wv-www.com
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Sherman Pendley, Nov 4, 2007
    #15
  16. Christian wrote:
    > I once heard the term "hotspotless" code used for GUI parts written in
    > pure java..
    > meaning that java's guis have the problem that they are not hot spots
    > .. as a user won't klick each button that often resulting in gui code
    > not being compiled down to native code but just allways being
    > interpreted which might result in an unreactive GUI as an effect (or at
    > least a GUI that is less reactive than a native couterpart)


    I find it hard to believe that the effect of like 20 statements
    in an actionPerformed being JIT'ed or not should be noticeable.

    A difference between 1 micro second and 20 microseconds is
    relative big. But a GUI user needs damn sharp eyes to notice
    the difference.

    Arne
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Nov 5, 2007
    #16
  17. Lew wrote:
    > Knute Johnson wrote:
    >> The coming JRE is going to have greatly improved startup performance.
    >>
    >> https://jdk6.dev.java.net/6uNea.html
    >>
    >> I've played with it a little bit on windows and there does seem to be
    >> some performance increase.

    >
    > If you really are talking about Java 6, it's been out already for almost
    > a year.
    >


    Read the article.

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Nov 5, 2007
    #17
  18. Roedy Green Guest

    On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
    <> wrote, quoted or indirectly quoted
    someone who said :

    >The coming JRE is going to have greatly improved startup performance.
    >
    >https://jdk6.dev.java.net/6uNea.html


    "The Quick Starter feature will prefetch portions of the JRE into
    memory, substantially decreasing the average JRE cold start-up time
    (the time that it takes to launch a Java application for the first
    time after a fresh reboot of a PC)."

    Sounds like they are loading a pre-loaded RAM image to get the basic
    classes going. Yea! I have been asking for this since day 1.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Nov 5, 2007
    #18
  19. Guest

    On Nov 4, 9:41 pm, wrote:
    > I am just interested in the latest stats on Java performance. A lot
    > of the literature appears to be out of date in this respect. Is it
    > true that Java performance is close to that of native compiled code?
    > I suppose it could be said that Java *is* natively compiled (at run
    > time), but there will surely be performance penalties due to bytecode
    > translation, at least at program startup.
    >
    > Can Java be used for graphics-intensive applications, such as the
    > latest 3D game, such as Doom/Quake/whatever is the current hot game.
    > If not, what are the issues that prohibit Java from being suitable.
    >
    > Finally, I have read that garbage collection is generally more
    > efficient than manual memory management. Is this true, and if so,
    > why?
    >
    > Please feel free to mention anything else that is relevant...
    >
    > Regards,
    > B.


    Thanks all for the responses. The feeling I am getting is that Java
    is not very suitable for apps where it needs to interact quite closely
    with the machine (such as graphics, device I/O) because of large
    runtime overhead of JNI. Can this overhead be circumvented by
    compiling Java to native code? Or is it unavoidable for some reason..

    Does Java suffer from GC pauses anymore(on UP systems), or are they a
    thing of the past?

    <OT> I am looking for a language that is as close to the metal as C++,
    yet has garbage collection, which I think is a better idea than manual
    mm. Any ideas? </OT>
    , Nov 5, 2007
    #19
  20. Roedy Green <> writes:

    > On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >>The coming JRE is going to have greatly improved startup performance.
    >>
    >>https://jdk6.dev.java.net/6uNea.html

    >
    > "The Quick Starter feature will prefetch portions of the JRE into
    > memory, substantially decreasing the average JRE cold start-up time
    > (the time that it takes to launch a Java application for the first
    > time after a fresh reboot of a PC)."
    >
    > Sounds like they are loading a pre-loaded RAM image to get the basic
    > classes going. Yea! I have been asking for this since day 1.


    That, or they are making yet another "QuickStart" that loads and takes
    up memory at boot time, whether you use it or not.
    It can sit next to Office QuickStart, Firefox Quickstart and
    a gazillion other programs that think they are so important that
    you have to start everything but the GUI every time you start
    your machine.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Nov 5, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jm
    Replies:
    1
    Views:
    507
    alien2_51
    Dec 12, 2003
  2. totojepast
    Replies:
    0
    Views:
    456
    totojepast
    Jul 10, 2003
  3. Ahmed Moustafa

    Java performance hints and tips?

    Ahmed Moustafa, Jul 14, 2003, in forum: Java
    Replies:
    9
    Views:
    651
    Ahmed Moustafa
    Jul 16, 2003
  4. David Zimmerman
    Replies:
    1
    Views:
    2,115
    Harald Kirsch
    Jul 22, 2003
  5. Software Engineer
    Replies:
    0
    Views:
    326
    Software Engineer
    Jun 10, 2011
Loading...

Share This Page