Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How much efficient is Java 6 to Java 1.3?

Reply
Thread Tools

How much efficient is Java 6 to Java 1.3?

 
 
Sanny
Guest
Posts: n/a
 
      04-12-2008
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
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      04-12-2008
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
 
Reply With Quote
 
 
 
 
jolz
Guest
Posts: n/a
 
      04-12-2008
> 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.
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-12-2008
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-12-2008
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
 
Reply With Quote
 
jolz
Guest
Posts: n/a
 
      04-12-2008
> 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/
StringLjava/lang/StringBuilder; (4)
11: aload_2
12: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
StringLjava/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/
StringLjava/lang/StringBuffer; (4)
11: aload_2
12: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
StringLjava/lang/StringBuffer; (4)
15: invokevirtual java.lang.StringBuffer.toString ()Ljava/lang/
String; (5)
18: areturn

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-12-2008
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/
> StringLjava/lang/StringBuilder; (4)
> 11: aload_2
> 12: invokevirtual java.lang.StringBuilder.append (Ljava/lang/
> StringLjava/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/
> StringLjava/lang/StringBuffer; (4)
> 11: aload_2
> 12: invokevirtual java.lang.StringBuffer.append (Ljava/lang/
> StringLjava/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

 
Reply With Quote
 
jolz
Guest
Posts: n/a
 
      04-12-2008
> 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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      04-12-2008
On Sat, 12 Apr 2008 14:38:50 -0400, Lew <(E-Mail Removed)> 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
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      04-12-2008
On Sat, 12 Apr 2008 14:45:21 -0400, Arne Vajh°j <(E-Mail Removed)>
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
DVD Soon or much much later? anthony DVD Video 10 07-08-2005 07:13 PM
Simulation questions...how much is too much? =?Utf-8?B?VGlwcHk=?= Microsoft Certification 0 04-16-2005 04:47 AM
CPU Heat--how much is too much? PowerPost2000 Computer Support 4 12-22-2003 12:40 AM
paranoia... much too much adcl Computer Support 14 11-08-2003 05:18 PM



Advertisments