One point you're missing (and it doesn't seem you're
alone) is that there is no need to shut down the JVM after
your "utility" is finished. You can just leave the JVM
sitting there, already warmed up and ready to go, just
waiting to be told to load another class.
This does presume the JVM will be needed, and if it is that's fine.
But it uses a fair amount of memory that other applications are now
locked out from -- either that or it has to be paged out, another hit
on system performance.
As a concrete example of this approach, consider a
browser running a sequence of applets, one after another.
Right, if the machine is running a large Java app like a application
web server, or if all your code snippets are java, then you'd
capitalize on the ready-to-go scenario of an already up and running
JVM.
The only actual data I've seen on this topic is now
quite old, dating from the first few years of Java. IIRC
it was an article in CACM, describing an experiment in
which several dozen computer science students wrote programs
using various languages: Java and C++ and C (I think). The
programs were then assessed for correctness and performance.
The average performance of the Java programs (I forget how
they defined "average" and "performance") was poorer than
that of programs in the other languages, *but* the variation
between languages was much smaller than the variation between
individual programmers. That is, performance depended much
more on programmer skill than on language choice. So the
answer to your question "How does one get Java to run faster"
may simply be "Write better code."
I believe the article was from an age before JIT, back
when Java really was a purely interpreted language. I don't
know whether the experiment has been repeated with more
recent implementations.
This kind of reminds me of my first stab at writing a java program
that I'll share -- feel free to scroll by if this is not of
interest...
My first experience with Java was about 1996 when for grits and shins
I wanted to compare Java against C, since we were doing a lot of C and
Java was this "new kid on the block.". So I decided to do a program
that had a reasonable balance of I/O vs computational load as a means
to compare -- it was a searching function ala "grep" to scan log files
on a telephony switch. The logs were over a megabyte with ASCII text
-- pretty standard "logs" if you will.
Both programs required a case-sensitive string enclosed in quotes as
input. I really didn't know any of the particulars of Java, but since
it was block structured I decided for a "fair" comparison I'd use the
same algorithm in both. The algorithm looked more or less like this:
int line = 0;
open file
while( ! eof )
{
buffer;
++line;
if( readline(buffer) == endoffile )
eof = true;
else if( buffer contains string )
print "found string on line #" line
}
close file;
The print was a printf in C and System.out.println in java. In C
buffer was declared as "char buffer[nnn]" and in Java it was a "String
buffer" -- for both it was declared inside the loop. The C search
used strstr(buffer, searchStr) and java used
buffer.indexOf(searchStr).
I know a lot of Java experts are shaking their heads, but remember I
didn't know the nuances of Java; I just knew it was block structured,
and perusing a Java reference book was enough to get it to compile.
The benchmarking test used an RS/6000 with AIX, and the results were
staggering. Tthe C program could search the entire log file and
produce the desired output in about 18 seconds. The Java version ran
for over 11 minutes before it finally blew off because it was out of
memory. I tried and retried and I could not get it to run through to
completion.
Of course today I know using a String was bad and that a StringBuffer
would have been better, plus declaring an Object inside the loop was
causing GC to run nonstop I imagine. I hadn't used any kind of
BufferedReader -- I don't remember what I used to be honest, but it
wasn't the best choice.
So admittedly, I made a lot of java "rookie" mistakes.
Anyways, the exercise was valuable, as I realized Java simplified some
things, but to be good it required some meta knowledge that wen't
beyond syntax and semantics -- it was very important what objects you
used, where you put them, and that you understood the side effects
caused by the objects (sync vs non-sync, immutable, etc) you used.
For those who only code in Java you're probably saying to yourself
"okay, everyone knows that, so your point is?" -- but if you use most
other languages, a buffer is pretty much a buffer, and whether it's
declared as an object or a character array doesn't have such a
dramatic effect on performance, so outside of the Java community it's
compelling. I went into my exercise unaware of this difference, and
needless to say I wasn't highly impressed with Java at that time.
Java's come a long way since then, and I've come a long way with Java,
too. I'm still learning more about the language and its nuances, and
I do like it. But I'm not so in love with any language, from C to
shining J, to explain away issues if they exist, so that's why I'm
intrigued by performance comparisons where java is said to outperform
natively compiled languages. On a fundamental level that's
impossible; but though ingenuity and circumstance, they do some pretty
amazing things with the language.
To me it still boils down to understanding the problem you're trying
to solve and selecting the best algorithms, language, architectures,
etc, that solve the problem. And I believe fundamentally in realizing
this is not the only problem to be solved, so keep in mind the impact
your solution will have on the other solutions running before,
concurrently and afterwards. Sometimes Java is ideal; other times
it's a bad choice because it's a heavyweight runtime; blindly applying
C, Java or whatever to every problem space isn't very wise.
At any rate, that's why I don't write much Java for my desktop at this
time -- most of what I run does not requrie a JVM, so to use Java + a
JVM to solve the quick-n-dirties on my workstation would be like
hunting mice with a howitzer. I write lots of Java in the Enterprise
world, on web servers, and to provide distributed services, all of it
engaged within the Spring framework, and it's extremely flexible, easy
to use, and nice.
Everything does have its place.
I do appreciate the responses... thanks!
