-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Bryce McKinlay
Sent: Monday, April 17, 2000 1:08 PM
To: gs
Cc: Classpath; [EMAIL PROTECTED]
Subject: Re: java.net: Classpath vs. libgcj Comparison
gs wrote:
> I hate to be picky about comments, but the way things are commented in
> libgcj is far from the 'standard'. I don't want to step on anyone's toes
> here, but this Classpath/libgcj implementation is probably going to be
more
> like a reference implementation than a benchmark-killer in the foreseeable
> future,
Why shouldn't it be a "benchmark-killer"? libgcj/gcj performance is already
comparable to the fastest proprietary implementations available (Sun's
Hotspot
VM and the IBM's JDK), and in some respects beats them. Being fast and being
a
good reference implementation are not necessarily contradictory.
I don't think this is an issue (who would disagree).. The issue is : which
is more important (during the merging process), performance or
useability/maintainability? (and how much rewriting should be done in the
merging process in order to get the best from both camps).
> IMO comments should be put in the header if
> possible, and in the method body only for non-intuitive stuff.
Comments in the method header should describe the function and behavior of a
method. Inline comments should explain specific implementation details, when
required.
> What I'm
> trying to say is that _lots_ of people are going to look to this
> implementation, therefore readability _has_ value.
I don't disagree with this point - and certainly it may occasionally be
desirable to sacrifice absolute performance in situations where it would
compromise the readability and maintainability of the code. However, the
ideal
implementation should be both clean and perform well. In the specific
example
of InetAddress.equal(), the two implementations are virtually identical.
However one makes an unnecessary call which can be replaced with a direct
reference to the field in question. This certainly does not compromise
readability, it makes the method faster, and arguably makes the
implementation
MORE correct.
This was not actually the essential point I was trying to communicate.
Rather,
my point is that we need to choose the best features of each existing method
and class when developing the merged implementation. Your original message
seemed to suggest that code would be chosen on a per-class basis to become
the
merged libgcj/classpath. I pointed out the imperfections in both equals()
implementations as an example of why this approach would be sub-optimal.
I agree. I did this comparison simply in order to outline the differences
between the two libraries, it was never meant to be a complete work, just a
base from where the ones responsible for the merge can start working.
> I disagree, the clone method more than likely does exactly what is done in
> the classpath version.
No!! If your runtime has a clue, then array cloning (like
System.arrayCopy())
uses memcpy() or some similar primitive to copy the array data efficiently.
This is almost always going to be more efficient than looping and copying
each
element by hand. Not only that, but it reduces 6 lines of code down to 1! A
cleaner implementation, and faster.
Where is my mind? byte[] is of course a primitive, I stand corrected.
regards
[ bryce ]
