How much efficient is Java 6 to Java 1.3?

[Sanny]

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

 

[Joshua Cranmer]

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.

 

[jolz]

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.

 

[Arne Vajhøj]

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]

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

 

[jolz]

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

 

[Arne Vajhøj]

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

 

[jolz]

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.

 

[Roedy Green]

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]

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.

 

[Andreas Leitgeb]

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

 

[Arne Vajhøj]

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]

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

 

[Roedy Green]

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]

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

What are they?

 

[Andreas Leitgeb]

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.

 

[Roedy Green]

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]

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]

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

 

[Andreas Leitgeb]

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.