On Dec 28, 2004, at 2:06 PM, Ceki G�lc� wrote:
The code currently says:
/**
* The hashcode is computed as XOR of the lower 32 bits of sequenceNumber and
* the higher 32 bits of timeStamp;
*/
public int hashCode() {
return (int)((timeStamp >> 32) ^ (sequenceNumber & 0xFFFFFFFF));
}
In what way does the comment not match the code?
Sorry, I misread the comment. Thought it said lower 32 bits of the timestamp.
The hashcode does not need to uniformly spread out the returned values over the range of integer. It just has to make a minimal effort to avoid that many values do not pile up on top of each other. Given that all hash tables algorithms compute the hash value over modulo 'n' where 'n' is a small prime number, for all practical purposes the following hashcode would have been amply sufficient.
public int hashCode() { return (int)((sequenceNumber & 0xFFFFFFFF)); }
We are doing a little better by XORing with the higher 32 bits of the timestamp. (2 to 32 milliseconds is about 50 days.) A slightly better implementation would have been
public int hashCode() { return (int)((timeStamp >> 20) ^ (sequenceNumber & 0xFFFFFFFF)); }
2^20 millis = 1048576 millis or about 17 minutes.
The point that I was trying to make and which I still think is valid despite my mistaken analysis of the hashCode function, is that it is better to have Chainsaw to make whatever comparison it thinks is appropriate for its filtering needs and avoid having to worry about maintaining the equals contract and having a hashCode function that results in good performance if LoggingEvents are added to a HashTable.
p.s. LoggingEvent has commented out methods xgetMDCCopy and XXgetMDCKeySet. Are these going to be deleted or uncommented?
They'll eventually be deleted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
