On 12/16/2010 3:02 PM, Wade Chandler wrote:
Now, the one place that doesn't seem a waste of time is using those unmarshalled
Entries and fields for lookup. Seems having those realized in memory already is
much faster. A way to speed up the overall effort would be to store the
serialized form along with the realized/unmarshalled form in the list or what
ever data structure since these held instances are immutable per the
write/read/take operations; no reserialization. Then the serialized form can be
returned immediately. More memory of course, but that could be limited with a
logical archiving mechanism for memory which hasn't been accessed for a period
of time (paging essentially of the serialized form). A hash, depending on size,
would of course work for that whether on disk or in memory.
Dwelling further, it doesn't seem probable to just take the Entry fields and
serialize them associate them with their hash (hashCode) and then use something
to compare those things because there is a possibility that hashCode hasn't been
overridden and thus equals and hashCode won't necessarily both represent
equality with the same meaning. Were there some guarantee that is the case, then
that would be possible to do.
This is the type of thought that I gave when deciding to split keys and values
in griddle, and to wrap them into an object which has a "matches" implementation
along with equals and hashCode. This allows "canned" matching to be in the
classpath of the server, so no "downloaded code" for that, as well as allow
unmarshalling of keys, which are intended to only ever be "native" types, or
types already in the classpath of the server.
Gregg Wonderly
