Optimising Java Programs

[Jeff]

Hi, I understand that Java applets are not the fastest applications, but
can anyone provide some information regarding optimising applets to make
them run as fast as possible? What things should be avoided when
attempting to make a fast applet program?

Thanks in advance

 

[Andrew Thompson]

Hi, I understand that Java applets are not the fastest applications,

Two things.

1) Generally, the term application is used
(in Java) to denote something that is _not_
an applet.

2) Java's perceived 'slowness' comes from
having to load the JRE, which can be several
megabytes or more before the applet/application
itself can be loaded and run. Once the JRE and
bytecodes are loaded, Java can run every bit as
fast as other languages.

Beyond that, a few general tips for increasing
the apparent speed of a Java app.

1) <http://www.physci.org/guifaq.jsp#2.1>

2) Keep the user updated. Three seconds looking
at a progress bar is a lot 'quicker' than three
seconds in which 'nothing happens'.

3) Do time consuming things either a) only when
necessary, or b) after the GUI has appeared
and the app. is waiting for user input.

Beyond that, you might Google java+optimization
and trawl the 1,260,000 hits that produces..

 

[Lars Broecker]

Hi, I understand that Java applets are not the fastest applications, but
can anyone provide some information regarding optimising applets to make
them run as fast as possible? What things should be avoided when
attempting to make a fast applet program?

There is a book from o'Reilly called "Java Performance Tuning". You
might want to take a look at that.

 

[Roedy Green]

Hi, I understand that Java applets are not the fastest applications, but
can anyone provide some information regarding optimising applets to make
them run as fast as possible? What things should be avoided when
attempting to make a fast applet program?

see profiler.html

The key in Java is not to write little tricks in the code. The
compiler mostly does that for you. The key is to minimise I/O and to
have an efficient algorithm.

You optimise for clarity, brevity and simplicity. When you are done,
you profile, then optimise only those bottlenecks for speed.
Optimising prematurely or everywhere makes the code hard to maintain.

 

[Roedy Green]

2) Java's perceived 'slowness' comes from
having to load the JRE, which can be several
megabytes or more before the applet/application
itself can be loaded and run. Once the JRE and
bytecodes are loaded, Java can run every bit as
fast as other languages.

And if you want to avoid that, use native compilation.

See http://mindprod.com/jgloss/nativecompiler.html

 

[FISH]

And if you want to avoid that, use native compilation.

See http://mindprod.com/jgloss/nativecompiler.html

If you aren't interested in WORM and you want speed, you'd be better off
ditching Java in favour of C++ (or similar).

You shouldn't be looking at running serious number crunching applications
(entirely) in Java. It's about having the right tool for the job - Java
can cope with most tasks without any problem, but it certainly is not a
Jack of all trades (nor should it ever be IMHO!) If you're having to
resort to creating native binaries from your Java code, you should
seriously consider whether you are using the right language...


-FISH- ><>

 

[Michael Borgwardt]

If you aren't interested in WORM and you want speed, you'd be better off
ditching Java in favour of C++ (or similar).

Nowadays that's not necessarily good advice at all.

You shouldn't be looking at running serious number crunching applications
(entirely) in Java.

Why not? It's in fact a field where the performance penalty
of Java is smallest or even negative, since you get the full
benefit of the JIT compiler.

 

[Roedy Green]

If you're having to
resort to creating native binaries from your Java code, you should
seriously consider whether you are using the right language...

What do you mean "resort"? There is no more reason to avoid
statically compiling Java than C.

Go away and hang out with JTK and the other shills in
comp.lang.java.advocacy. This is not the place to spread lies about
Java.

 

[FISH]

What do you mean "resort"? There is no more reason to avoid
statically compiling Java than C.

So you don't hold with the Write Once... phylosophy? ;-)

Go away and hang out with JTK and the other shills in
comp.lang.java.advocacy. This is not the place to spread lies about
Java.

Which lies would that be, exactly...? (Or do you just do around
accusing people of lying for the hell of it...

As you point out, this isn't clja, so you can turn off 'auto-flame and
'auto-pedantic'.

It annoys me, slightly, the attitude which seems to be coming more common
(thanks in part no doubt to it being prompted by Microsoft) that
programming languages are lifestyle choices, like the colour of your
car, or pop versus rock music. More and more, it seems, people want to
focus on only one language, and use that for everything they code. Then
they childishly bash any language which isn't their own. And rather than
choosing another language when their encounter a weakness in their choosen
one, they resort to tricks and hacks to get by.

(Indeed the whold idea of language advocacy is a misnomer. Languages are
tools, each with strengths and weaknesses. Could you imagine "rec.diy. -
hammer.advocacy" battling it out with "rec.diy.spanner.advocacy"? )

Today, when I suggested using Perl to fix a problem with some CSV files
that the Oracle DBA where I work needed to import, I got a lot of joke
comments from other programmers to the effect of "have you abandoned
Java?". Like I'm not allowed to use another language without somehow
betraying Java...

Now Java has many many (many many...) strengths. But speed generally
(with a few exceptions) isn't one of them. And compiling to native
binary is a hack... oh I know all the Java fanboys will scream and
shout, but the whole point of Java is to avoid being tied to a given
hardware/OS platform.

You *can* compile Java to binary. You *can* turn C into a slow
scripting language. You can do all kinds of things. But ultimately
you are usually better of just choosing the right tool for the job...
rather than subverting one because you have some kind of pseudo-
religious attachment to it!!!

I'm all in favour if languages being enhanced and updated (ie. generics
in Java 1.5) but I do think this attitude that a language should be all
things to all men is a little silly. I'd rather not have to use
languages which were Jacks of all trades, and masters of none. (Can
you say C#? ;-)


-FISH- ><>

 

[Roedy Green]

Which lies would that be, exactly...?

This is a technical group. There is a special place to have fights of
this sort, comp.lang.java.advocacy. You are off topic.

Go away.

 

[FISH]

Nowadays that's not necessarily good advice at all.

Perhaps I put it a little too strongly(?) Perhaps "you'd be better off
considering other languages as well" ?

Why not? It's in fact a field where the performance penalty
of Java is smallest or even negative, since you get the full
benefit of the JIT compiler.

You mean the Hotspot compiler, surely?

Although I have been explaining to colleagues about the theoretical
speed benefits of Java since that article by Sun engineer Scott Oaks
(?) in Java Report (Spring 1997, IIRC), it has to be said that Java
generally still does not perform at the same level of speed as
optimised C/C++ code for many applications.

As Hotspot and other compiler technologies advance, I hope that
Java will achieve the goal hinted at in the afore-mentioned article,
and actually run faster in 'real world' circumstances than C (and
other natively compiled language) code. But so far that goal has
been largely unreached.


-FISH- ><>

 

[FISH]

This is a technical group. There is a special place to have fights of
this sort, comp.lang.java.advocacy. You are off topic.

Go away.

Roedy, stop it with the knee-jerk 'clj.advocacy-style' flaming. You
are better than that! I expressed a prefectly valid - AND ON TOPIC -
point, that if you want serious speed you should consider languages
other than Java. (I should have said 'also consider' - as noted
elsewhere in this thread!) Java has many strengths, but right at this
moment raw naked speed usually (save for a few particular circumstances)
isn't one of them.

I also commented, later on, that using native compilers on Java runs
against the grain of the language/etc - given that one of its core
goals is platform neutralist and WORM. If one wants software which
behaves like it was written in a native compiled language, one should
seriously consider using languages which are designed for that purpose,
rather than mis-using Java. (Again, this is not a black and white issue,
and there is room for intelligent discussion as to when it is and is
not appropriate to run against the grain of a language in this way!)

Now, the clj.programmer response to this would be to consider what was
written, and start an intelligent discussion on the matter (as indeed
one other follow-up did to the original post - pointing out that with
Hotspot there are occassions where Java can out perform C... a
perfectly valid point to make.)

The clj.advocacy response would be to treat *any* critisism of Java as
an act of war, start calling everyone within a 50 yard radius a liar,
and generally do *ANYTHING* except actually discuss the matter at hand...

;-)

[Note: I've not cross-posted or reassigned this posting to advocacy,
as I still hold out hope... ]


-FISH- ><>

 

[FISH]

This is a technical group. There is a special place to have fights of
this sort, comp.lang.java.advocacy. You are off topic.

Go away.

ps. If you are going to snip someone's post, please do not remove the
smiley's from the end of comments. They can change the context of a
statement quite dramatically - and quoting out of context often
promotes misunderstanding. We wouldn't want that on a non-advocacy
group, surely...? ;-)

===================^^^ (Smiley)

 

[Bent C Dalager]

(Indeed the whold idea of language advocacy is a misnomer. Languages are
tools, each with strengths and weaknesses. Could you imagine "rec.diy. -
hammer.advocacy" battling it out with "rec.diy.spanner.advocacy"? )

Seeing as this is Usenet we're talking, yes I most certainly could.

I could also imagine the debate spilling over into rec.diy.hammer and
rec.diy.spanner, prompting the creation of rec.diy.hammer.moderated
and rec.diy.spanner.moderated

Cheers
Bent D

 

[Jesper Nordenberg]

Roedy, stop it with the knee-jerk 'clj.advocacy-style' flaming. You
are better than that! I expressed a prefectly valid - AND ON TOPIC -
point, that if you want serious speed you should consider languages
other than Java. (I should have said 'also consider' - as noted
elsewhere in this thread!) Java has many strengths, but right at this
moment raw naked speed usually (save for a few particular circumstances)
isn't one of them.

Roedy has a point. Posting comments like "If you aren't interested in
WORM and you want speed, you'd be better off ditching Java in favour
of C++ (or similar)." to a Java programming group is not very
informative if you can't state why you think so and back it up with
benchmarks. Quoting an report from 1997 isn't helping much. If you
haven't noticed, Java has evolved quite a bit in the last couple of
years.

/Jesper Nordenberg

 

[Mark A. Washburn]

Hi, I understand that Java applets are not the fastest applications, but
can anyone provide some information regarding optimising applets to make
them run as fast as possible? What things should be avoided when
attempting to make a fast applet program?

Thanks in advance

Java applets must execute their functions thru bytecode. It's not,
necessarily,
that the Java language is over-restrictive in optimizability, in
programming language theory, it's the bytecode, thru with every Java
Applet must operate.

If you really need to learn how to develop high efficiency Applets,
study Applets that have already been made. If the source code isn't
available, as may be the case with high performance Applets, you may
want to try a bytecode to source code tool.

But, basically, you are correct. Java Applets will not show the
performance anywhere close to hand crafted machine code or C code.

If you would like to read more about the difference between compiling
Java to bytecode v.s. compiling Java to machine code, you may wish
start with reading "4.2 Can GCJ only handle source code?" in the GCJ
FAQ, http://gcc.gnu.org/java/faq.html.

Here is my wisdom for high efficiency Applets, program as close as
possible to the Sun's library native methods.

maw

 

[FISH]

Roedy has a point. Posting comments like "If you aren't interested in
WORM and you want speed, you'd be better off ditching Java in favour
of C++ (or similar)." to a Java programming group is not very
informative if you can't state why you think so and back it up with
benchmarks.

The paragraph which followed that comment *did* expand my opinions
on the matter. As indeed did the lengthy posting which followed. As
for benchmarks, I didn't think they were necessary in this instance,
as the point I was responding to was about using a native compiler to
overcome any potential shortcomings in Java's speed - ergo the fact
that Java might have issues in that area (necessitating a native
compiler) was implicit in the discussion.

Perhaps I didn't make clear enough in the second para that not
resorting to 'tricks' to overcome language shortcomings was merely
an opinion - not quoted as fact/law - as indeed are most comments
on Usenet. It is an ethical issue more than anything else, and as
such I'm not sure how one would go about 'benchmarking' ethics.
Even so, the correct response is surely to query the comments or
ask for clarity, not to flame. (As Roedy points out, this is not
an advocacy group.)

Quoting an report from 1997 isn't helping much. If you
haven't noticed, Java has evolved quite a bit in the last couple of
years.

Well it would seem that neither of us have posted benchmarks to
prove that Java (run via a JVM) is or is not generally faster than
natively compiled code. I merely hold *an opinion*, based upon
nothing more than experience and anecdotal evidence, that Bytecode/
JVM beats native code only in a handful of very specific circum-
stances. I was under the impression that this was a generally held
opinion within the intelligent (ie. not fanboy) Java circles.

Perhaps I am wrong. (Which begs the question, why are people
suggesting resorting to native compilers if the JVM is generally
faster?) I know that in theory at least Java *can CONSISTANTLY*
beat native code - as the article I mentioned proves - but I was
unaware that anyone was seriously suggesting it had reached that
stage yet. (Or indeed that it would do so for some time!)

Even so, I still maintain that running Java through native compilers
(producing a .EXE, for example) goes against what the language stands
for. I find it ironic that Sun had to battle Microsoft to defend
Java's platform neutrality, and here are a handful of Java programmers
willfully surrendering it! If you know you need to compile to .EXE
then you should pause to question whether Java is the right tool for
the job at hand - *regardless* of whether this is a speed issue. But
there is no right or wrong here, just 'ethics', so no benchmarks can
save us...


-FISH- ><>

 

[Michael Borgwardt]

Perhaps I put it a little too strongly(?) Perhaps "you'd be better off
considering other languages as well" ?

I wouldn't hesitate to agree with that.

You mean the Hotspot compiler, surely?

No, I mean JIT compilers in general. Hotspot is not the only one that can do
special optimization tricks.

Although I have been explaining to colleagues about the theoretical
speed benefits of Java since that article by Sun engineer Scott Oaks
(?) in Java Report (Spring 1997, IIRC), it has to be said that Java
generally still does not perform at the same level of speed as
optimised C/C++ code for many applications.

As Hotspot and other compiler technologies advance, I hope that
Java will achieve the goal hinted at in the afore-mentioned article,
and actually run faster in 'real world' circumstances than C (and
other natively compiled language) code. But so far that goal has
been largely unreached.

But the problems that prevent this do NOT lie in the kind of code
a number-crunching application uses, which is the kind if code that
is most easy to optimize for compilers.

 

[Jesper Nordenberg]

The paragraph which followed that comment *did* expand my opinions
on the matter. As indeed did the lengthy posting which followed.

But you didn't explain the reason for your opinions. Just posting your
opinions doesn't help anyone. You stated that "You shouldn't be
looking at running serious number crunching applications (entirely) in
Java.", without explaining why and in which cases you think Java is a
bad choice. Without those arguments your post is just a subjective
opinion.

As
for benchmarks, I didn't think they were necessary in this instance,
as the point I was responding to was about using a native compiler to
overcome any potential shortcomings in Java's speed - ergo the fact
that Java might have issues in that area (necessitating a native
compiler) was implicit in the discussion.

No, the reason why Roedy mentioned native compilation was because it
often reduces the load time of a Java application. It was a reply to a
post that mentioned this as a problem. The issue was not if native
compilation would increase the run speed of the Java application
(which it in most cases don't do).

Well it would seem that neither of us have posted benchmarks to
prove that Java (run via a JVM) is or is not generally faster than
natively compiled code. I merely hold *an opinion*, based upon
nothing more than experience and anecdotal evidence, that Bytecode/
JVM beats native code only in a handful of very specific circum-
stances. I was under the impression that this was a generally held
opinion within the intelligent (ie. not fanboy) Java circles.

It's the general opinion in ignorant anti-Java groups. Those who
haven't tried Java since version 1.1.

Perhaps I am wrong. (Which begs the question, why are people
suggesting resorting to native compilers if the JVM is generally
faster?)

Three reasons: faster startup, less memory usage and easier deployment
in some cases.

I know that in theory at least Java *can CONSISTANTLY*
beat native code - as the article I mentioned proves - but I was
unaware that anyone was seriously suggesting it had reached that
stage yet. (Or indeed that it would do so for some time!)

You should read up on the latest research articles about Hotspot and
other JVM's. I'm not saying the JVM is always faster than native
compiled code, but if you state the contrary I want some proof, not
just a subjective opinion.

/Jesper Nordenberg

 

[Roedy Green]

The issue was not if native
compilation would increase the run speed of the Java application
(which it in most cases don't do).

I find it does, but not that much. The gain mostly is in startup
time.

Most of my stuff is i/o bound anyway.