How much efficient is Java 6 to Java 1.3?

Discussion in 'Java' started by Sanny, Apr 12, 2008.

  1. Sanny

    Sanny Guest

    I have an Applet designed using Java1.3

    Since the people browsing the applets are using Java 6 / 7 (Latest
    version) They already getting advantage of higher version.

    Should I compile the code with Java 6 to get higher performance? Will
    that speed up the Applet processing?

    That applet was compiled using Java 1.3, Will recompiling speed up the
    applet. Will I be seeing a 100 %/ 200 % Jump in Applet speed?

    Bye
    Sanny

    Java Experts Needed: http://www.getclub.com/Experts.php
     
    Sanny, Apr 12, 2008
    #1
    1. Advertising

  2. Sanny wrote:
    > I have an Applet designed using Java1.3
    >
    > Since the people browsing the applets are using Java 6 / 7 (Latest
    > version) They already getting advantage of higher version.


    The latest full release version is Java 6; Java 7 is (last I checked)
    still in alpha builds.

    > Should I compile the code with Java 6 to get higher performance? Will
    > that speed up the Applet processing?


    Do you have the source code? If not, you probably can't legally
    decompile it and then recompile to Java 6; in any case, decompilers
    still need some tweaking of the outputs to compile correctly.

    That said, you will not get any speed increase by recompiling the code
    with a newer compiler. Unlike software compiled to native code, Java's
    optimization comes at runtime. Even code written in Java 1.0 will have
    the same optimizations applied as code in Java 6.

    However, it may be possible that the applet is using antiquated, slow
    libraries (e.g., Vector instead of LinkedList or ArrayList). Any further
    speed enhancements you could get would require you to rewrite the code
    to use this newer stuff.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Apr 12, 2008
    #2
    1. Advertising

  3. Sanny

    jolz Guest

    > That said, you will not get any speed increase by recompiling the code
    > with a newer compiler. Unlike software compiled to native code, Java's
    > optimization comes at runtime. Even code written in Java 1.0 will have
    > the same optimizations applied as code in Java 6.


    Yes, optimization is done at runtime, but newer compiler may generate
    different code. And it does. For example addition of strings in 1.3
    uses StringBuffer, but in 6.0 StringBuilder that is supposed to be
    faster.
     
    jolz, Apr 12, 2008
    #3
  4. Sanny

    Arne Vajhøj Guest

    jolz wrote:
    >> That said, you will not get any speed increase by recompiling the code
    >> with a newer compiler. Unlike software compiled to native code, Java's
    >> optimization comes at runtime. Even code written in Java 1.0 will have
    >> the same optimizations applied as code in Java 6.

    >
    > Yes, optimization is done at runtime, but newer compiler may generate
    > different code. And it does. For example addition of strings in 1.3
    > uses StringBuffer, but in 6.0 StringBuilder that is supposed to be
    > faster.


    I doubt that effect will be measurable.

    Arne
     
    Arne Vajhøj, Apr 12, 2008
    #4
  5. Sanny

    Arne Vajhøj Guest

    Sanny wrote:
    > I have an Applet designed using Java1.3
    >
    > Since the people browsing the applets are using Java 6 / 7 (Latest
    > version) They already getting advantage of higher version.
    >
    > Should I compile the code with Java 6 to get higher performance? Will
    > that speed up the Applet processing?
    >
    > That applet was compiled using Java 1.3, Will recompiling speed up the
    > applet. Will I be seeing a 100 %/ 200 % Jump in Applet speed?


    You will see approx. 0% jump, because it is the JVM not the
    compiler that does the optimization.

    The 1.6.0 JVM are much faster than the 1.3.1 JVM - a 100%
    jump for number crunching type of app is not unrealistic.

    But speed of an applet would probably depend more on the
    native calls made for GUI than on the JIT compilers
    optimization.

    I believe that the GUI stuff has also been improved from 1.3.1
    to 1.6.0, but I do not have any numbers. And I would expect that
    part to be very platform specific as well. The JIT compiler be
    about identical on Windows and Linux/x86, but thenative GUI calls will
    be very different.

    Arne
     
    Arne Vajhøj, Apr 12, 2008
    #5
  6. Sanny

    jolz Guest

    > Joshua Cranmer's point would apply here, then - in order to get the benefit of
    > StringBuilder you'd have to rewrite the class that uses StringBuffer.


    No. The same sorce code will generate different bytecode. For example:

    public class A {
    String s(String s1, String s2) {
    return s1 + s2;
    }
    }

    Comiled with 1.6:

    0: new <java.lang.StringBuilder> (2)
    3: dup
    4: invokespecial java.lang.StringBuilder.<init> ()V (3)
    7: aload_1
    8: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
    String;)Ljava/lang/StringBuilder; (4)
    11: aload_2
    12: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
    String;)Ljava/lang/StringBuilder; (4)
    15: invokevirtual java.lang.StringBuilder.toString ()Ljava/lang/
    String; (5)
    18: areturn

    And compiled with 1.3:

    0: new <java.lang.StringBuffer> (2)
    3: dup
    4: invokespecial java.lang.StringBuffer.<init> ()V (3)
    7: aload_1
    8: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
    String;)Ljava/lang/StringBuffer; (4)
    11: aload_2
    12: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
    String;)Ljava/lang/StringBuffer; (4)
    15: invokevirtual java.lang.StringBuffer.toString ()Ljava/lang/
    String; (5)
    18: areturn
     
    jolz, Apr 12, 2008
    #6
  7. Sanny

    Arne Vajhøj Guest

    jolz wrote:
    >> Joshua Cranmer's point would apply here, then - in order to get the benefit of
    >> StringBuilder you'd have to rewrite the class that uses StringBuffer.

    >
    > No. The same sorce code will generate different bytecode. For example:
    >
    > public class A {
    > String s(String s1, String s2) {
    > return s1 + s2;
    > }
    > }
    >
    > Comiled with 1.6:
    >
    > 0: new <java.lang.StringBuilder> (2)
    > 3: dup
    > 4: invokespecial java.lang.StringBuilder.<init> ()V (3)
    > 7: aload_1
    > 8: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
    > String;)Ljava/lang/StringBuilder; (4)
    > 11: aload_2
    > 12: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
    > String;)Ljava/lang/StringBuilder; (4)
    > 15: invokevirtual java.lang.StringBuilder.toString ()Ljava/lang/
    > String; (5)
    > 18: areturn
    >
    > And compiled with 1.3:
    >
    > 0: new <java.lang.StringBuffer> (2)
    > 3: dup
    > 4: invokespecial java.lang.StringBuffer.<init> ()V (3)
    > 7: aload_1
    > 8: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
    > String;)Ljava/lang/StringBuffer; (4)
    > 11: aload_2
    > 12: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
    > String;)Ljava/lang/StringBuffer; (4)
    > 15: invokevirtual java.lang.StringBuffer.toString ()Ljava/lang/
    > String; (5)
    > 18: areturn


    They more or less had to switch.

    They put the following in the docs for StringBuffer:

    "The StringBuilder class should generally be used in preference to this
    one,"

    And if they have to eat their own dog food then ...

    And it is slightly faste. But we are down in the nanoseconds magnitude.

    Arne
     
    Arne Vajhøj, Apr 12, 2008
    #7
  8. Sanny

    jolz Guest

    > The code doesn't explicitly use either StringBuilder *or* StringBuffer, it
    > uses 'String'.  Other JVMs might not do that the same way.


    That's exactly my point. Recompilation may generate different code,
    which can be faster. Differences may or may not be measurable
    (actually I agree that probably won't be), but if speed is really
    important and applet does a lot of calculations there's no reason not
    to recompile and benchmark.
     
    jolz, Apr 12, 2008
    #8
  9. Sanny

    Roedy Green Guest

    On Sat, 12 Apr 2008 14:38:50 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >The code doesn't explicitly use either StringBuilder *or* StringBuffer, it
    >uses 'String'. Other JVMs might not do that the same way.


    Javac.exe is the one which makes the decision how the + concatenation
    operator is handled. So it would help to recompile with JDK 1.6 and
    target -1.6.

    Of course it won't change any EXPLICIT use of StringBuffer to
    StringBuilder.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #9
  10. Sanny

    Roedy Green Guest

    On Sat, 12 Apr 2008 14:45:21 -0400, Arne Vajhøj <>
    wrote, quoted or indirectly quoted someone who said :

    >And it is slightly faste. But we are down in the nanoseconds magnitude.


    StringBuilder was much faster than StringBuffer, then Sun improved the
    code for locking so the gain was reduced. Ditto for Vector and
    ArrayList.

    As optimisers get more and more clever it gets less an less important
    precisely how you specify your algorithm.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #10
  11. performance improving tactics vs. optimizer. (was: Re: How much efficient is Java 6 to Java 1.3?)

    Roedy Green <> wrote:
    > As optimisers get more and more clever it gets less an less important
    > precisely how you specify your algorithm.


    I wonder, if optimizers are or will (ever) be able to optimize
    even this particular anti-pattern:

    String s="";
    for(<whateveloop>) {
    s+= <something> ; <...>
    }

    such that only one StringBuilder is used, rather than one for
    each iteration.(*)

    Theoretically, it doesn't seem entirely infeasible to me.

    For readers of a certain other current (sub-)thread:
    (*) This would be one case, where re-using the StringBuilder
    would be much more efficient after all, because it's state
    at the end of each iteration is exactly what it would be
    initialized to for the next one. The "t4(re-init)" would
    be 0 here, quite unlike the t4(init to "s"'s content).
     
    Andreas Leitgeb, Apr 12, 2008
    #11
  12. Sanny

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On Sat, 12 Apr 2008 14:45:21 -0400, Arne Vajhøj <>
    > wrote, quoted or indirectly quoted someone who said :
    >> And it is slightly faste. But we are down in the nanoseconds magnitude.

    >
    > StringBuilder was much faster than StringBuffer, then Sun improved the
    > code for locking so the gain was reduced. Ditto for Vector and
    > ArrayList.


    StringBuilder was introduced in 1.5 - I think most of the
    improvements in synchronization had already been done.

    ArrayList was introduced in 1.2 and that was an entire different
    matter.

    If I were to guess then it was at least as important to
    avoid the frequent mistakes caused by people who thought
    using a thread safe class would make their code thread safe
    than for the performance gain. But it is pure speculation.

    Arne
     
    Arne Vajhøj, Apr 13, 2008
    #12
  13. Sanny

    Arne Vajhøj Guest

    Re: performance improving tactics vs. optimizer.

    Andreas Leitgeb wrote:
    > I wonder, if optimizers are or will (ever) be able to optimize
    > even this particular anti-pattern:
    >
    > String s="";
    > for(<whateveloop>) {
    > s+= <something> ; <...>
    > }
    >
    > such that only one StringBuilder is used, rather than one for
    > each iteration.(*)
    >
    > Theoretically, it doesn't seem entirely infeasible to me.


    Unless there is something in the JLS or VM Spec that
    prohibits this type of optimization, then it should
    indeed be possible.

    Arne
     
    Arne Vajhøj, Apr 13, 2008
    #13
  14. Sanny

    Roedy Green Guest

    Re: performance improving tactics vs. optimizer. (was: Re: How much efficient is Java 6 to Java 1.3?)

    On 12 Apr 2008 22:22:35 GMT, Andreas Leitgeb
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >I wonder, if optimizers are or will (ever) be able to optimize
    >even this particular anti-pattern:


    see http://mindprod.com/project/stringbuilderoptimiser.html
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 13, 2008
    #14
  15. Sanny

    Roedy Green Guest

    On Sat, 12 Apr 2008 20:56:41 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >However, the reasons to use ArrayList in preference to Vector are not related
    >to performance.


    What are they?
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 13, 2008
    #15
  16. Re: performance improving tactics vs. optimizer. (was: Re: How much efficient is Java 6 to Java 1.3?)

    Roedy Green <> wrote:
    ><> wrote:
    >>I wonder, if optimizers are or will (ever) be able to optimize
    >>even this particular anti-pattern:

    > see http://mindprod.com/project/stringbuilderoptimiser.html


    "Estimated Existing Implementations": 0 :-(

    PS:
    That reminds me of another of your project-suggestions, namely
    http://mindprod.com/project/interfacefinder.html
    Some time ago, I asked you to change the text from
    "Split it at the semicolons"
    to
    "Split it at occurrances of File.pathSeparator"

    But you didn't show any reaction at all, not even one like "I'm a
    Windows guy, and don't care about teaching portability", so I'm not
    sure you even read my previous bug-reports. I hope, you see it this
    time.
     
    Andreas Leitgeb, Apr 13, 2008
    #16
  17. Sanny

    Roedy Green Guest

    Re: performance improving tactics vs. optimizer. (was: Re: How much efficient is Java 6 to Java 1.3?)

    On 13 Apr 2008 09:47:54 GMT, Andreas Leitgeb
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >But you didn't show any reaction at all, not even one like "I'm a
    >Windows guy, and don't care about teaching portability", so I'm not
    >sure you even read my previous bug-reports. I


    I don't read all the messages in the newsgroups, and even the ones I
    do read I mostly skim, so it won't necessarily register you are asking
    for a change to the text on one of my web pages. If you want to make
    sure I notice, email me. see http://mindprod.com/contact/contact.html

    Subject: Error on http://mindprod.com/project/interfacefinder.html

    will help me notice even if the spam filter misfiles.

    I tried several times to get Linux to co-exist with Windows , but all
    it does it trash my partition tables requiring a from scratch
    reinstall of everything. That is inexcusable. I want Windows to fade
    into the sunset, but if Linunoids are going to make installs so
    difficult, that can't happen. The initial install has to be
    idiot-proof.

    Those essays at http://mindprod.com/project/projects.html are just
    project suggestions, to give you then general idea of what you might
    do for a project, not specifications. Your beef should primarily be
    with someone who implemented them in an unnecessarily
    platform-specific way.

    Any any rate, your correction will be in there within the hour.

    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 14, 2008
    #17
  18. Sanny

    Roedy Green Guest

    Re: performance improving tactics vs. optimizer.

    On Sun, 13 Apr 2008 08:48:17 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    > That's only one hop longer than a direct load of the
    >character. Part of the student project (excellent service to the community to
    >post those projects, btw) should be to benchmark the difference between the
    >String- and character-argument calls before implementing the optimization, and
    >to compare any change in the String-argument call times to that difference as
    >well.


    When you are writing general purpose optimisers you go for broke. You
    shave every nanosecond you can. It may matter to someone, even if
    just an artificial benchmark against the competition.

    For a given application, of course, you measure and don't bother with
    negligible optimisations.


    To an assembler programmer such as myself append(' ') is obviously
    vastly faster than append (" "). Because it is a trivial
    optimisation, so you might as well do it.

    append( ' ' )
    might be optimised roughly like this:

    if ( ++bufflen >= bufflimt ) { handleOverflow() };
    buff[ bufflen ] = ' ';


    append( " ")
    will be roughly implemented like this:

    int end = bufflen + literalxxx.length();
    if (end >= bufflimt ) { handleOverflow() };
    for ( int i = 0; i< literalxxx.length(); i++ )
    {
    buff[ bufflen + i ] = literalxxx[ i ];
    }
    bufflen = end;


    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 14, 2008
    #18
  19. Sanny

    Roedy Green Guest

    On Sat, 12 Apr 2008 23:05:28 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >To me, one reason is Occam's Razor, loosely speaking.


    I have added this to the entry on "ArrayList" at
    http://mindprod.com/jgloss/arraylist.html to summarise your objections
    to Vector.

    "Don't use Vector in new code. It has confusing redundant methods,
    and the synchronisation is excessive and implicit."
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 14, 2008
    #19
  20. Re: performance improving tactics vs. optimizer. (was: Re: How much efficient is Java 6 to Java 1.3?)

    Roedy Green <> wrote:
    > On 13 Apr 2008 09:47:54 GMT, Andreas Leitgeb wrote:
    >>But you didn't show any reaction at all, ...

    > I don't read all the messages in the newsgroups, and even the ones I
    > do read I mostly skim, so it won't necessarily register you are asking
    > for a change to the text on one of my web pages. If you want to make
    > sure I notice, email me. see http://mindprod.com/contact/contact.html
    > Subject: Error on http://mindprod.com/project/interfacefinder.html


    I did email you, but quite likely with a different one than what you
    suggested here.

    > will help me notice even if the spam filter misfiles.


    That might have happened.

    > I tried several times to get Linux to co-exist with Windows,


    This is of course not a forum to discuss windows+linux
    co-installation, and I'm not even able to help much anyway,
    since my machines are linux only since roughly a decade.

    I casually read remarks by others who complained that the
    installation procedures that worked with some version of
    windows suddenly stopped working with some newer version
    of windows, so this gives me some idea of the culprit.

    > Those essays at http://mindprod.com/project/projects.html are just
    > project suggestions, to give you then general idea of what you might
    > do for a project, not specifications. Your beef should primarily be
    > with someone who implemented them in an unnecessarily
    > platform-specific way.

    Generally, you're right, unless the platform-lock is already
    (inadvertedly) suggested in the outset.

    > Any any rate, your correction will be in there within the hour.


    It's better now, but I think it would be best to principially
    suggest File.pathSeperator, pointing out that this way should
    be the preferred one over any hardcoding of platform-specific
    values. As it is now, it sounds like: only if you're really
    really sure that you need it to run on more platforms, use
    the pathSeparator...

    Your students'-projects surely have some teaching effect from
    their very outset, so let's not teach the wrong message.
     
    Andreas Leitgeb, Apr 14, 2008
    #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. Sanny
    Replies:
    12
    Views:
    581
    Andrew Thompson
    Dec 15, 2006
  2. Replies:
    3
    Views:
    318
    Stuart Redmann
    Feb 16, 2007
  3. batlowese
    Replies:
    6
    Views:
    488
    Roedy Green
    Dec 21, 2007
  4. cpp4ever
    Replies:
    3
    Views:
    376
    Francesco
    Sep 8, 2009
  5. Raymond Schanks
    Replies:
    0
    Views:
    533
    Raymond Schanks
    Apr 11, 2010
Loading...

Share This Page