«

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

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

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

> 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

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

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

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

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