Re: Help me!! Why java is so popular
In article <1170878312.255778.127390@v33g2000cwv.googlegroups.com>,
raddog58c <raddog@kc.rr.com> wrote:
[ snip ]
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...
Some belated "just curious" questions here .... :
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" --
String or StringBuffer?
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,
Well, I'm no Java expert, just someone with intermediate-level
experience with the language, but -- I don't spot anything about
your pseudocode that's obviously bad. ?
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.
Dramatic results, all right. It might be interesting to repeat this
test sometime .... Hm, it might be interesting to first repeat it
using your original code (since Java compilers / runtime systems
have improved) and again with code written using what you now know
about Java.
Of course today I know using a String was bad and that a StringBuffer
would have been better,
It would? You're not changing the contents of the lines you read
from the file, so how would a StringBuffer be better?
plus declaring an Object inside the loop was
causing GC to run nonstop I imagine.
But, of course, you're not doing that; you're declaring an object
reference.
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.
Now *that* I can imagine making a difference.
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.
I'm not convinced that this makes Java different from other languages,
though. It seems to me that there are two issues here: whether
familiarity with the language's quirks can have a dramatic impact
on performance, and quality of implementation (compiler, library,
runtime system if any).
With regard to whether familiarity with the language's quirks can
affect performance, the obvious answer is "of course it can" -- and
I don't quite get how Java is different from C++, or any other
language, in that regard.
With regard to quality of implementation, well, as I said above,
I wonder whether if you repeated your tests now you would get the
same results. As I understand it, and as others have described,
changes to Java implementations over the years have resulted in the
potential for much better performance.
I did something along similar lines a few years back -- rewrote a C
program to compute something Mandelbrot-set-related (in which most
of the computation involves calculations using complex numbers) in
C++, specifically so I could replace the ugly use of two doubles to
represent each complex number with instances of a class for complex
numbers, complete with appropriate operator overloading. The resulting
program was a lot prettier but was slower by a factor of about 1.5.
To me this was a convincing demonstration that there *are* situations
in which it's a good idea to focus more on performance than on making
the code pretty, and I cited it often. Not too long ago, though,
I repeated this experiment and found .... that the C++ program ran
just as fast as the original C. So much for my nice example!
I guess my point is that claims about performance maybe have to be
re-evaluated from time to time. <shrug>, maybe.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.