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.
> 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 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.
regards
[ bryce ]
