Hello, I've worked a bit on improving the perfomance of equals() and hashCode() for the generated message clases.
The default implementations (from AbstractMessage) are (relatively)
slow; equals() consumes additional memory by allocating four throwaway
Maps per call, and hashCode() two Maps per call.
This might not be relevant for many people, but in my case doing stuff
like List.contains() is severly impacted.
The above does not apply to LITE messages from what I can tell, they
just use the standard Object implementation of these methods (which I
find quite inappropiate for the kind of data protobuf objects are
supposed to represent).
My implementation of equals() compares the two messages
field-by-field. In tests, for equal objects it is about an order of
magnitude faster than the default.
The hashCode() value is cached (the objects are supposed to be
immutable anyway), speeding up equals() in the not-equal case by
another order of magnitude.
For LITE messages, which don't use the AbstractMessage
implementations, the hashCode is computed by going through all the
fields.
The only downside is that the size of the generated classes increases
(additional bytecode), proportional to the number of fields in the
message.
Would love to hear feedback on the patch -- anyone finding it useful /
appropiate?
Cheers,
-pwr
P.S. The patch is for protobuf-2.2.0.
--
Time is an illusion. Lunchtime doubly so.
-- Douglas Adams
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
improved_equals.diff
Description: Binary data
