On Mar 2, 2009, at 1:18 PM, Andrew Lindesay wrote:
Hello Chuck;
A big part of slowing-down with saturated object stores is that as
there are more and more EO's in memory it takes longer and longer
for fetches to be processed because as the system ensures
uniqueness, it will have to keep checking to see if it already has
each new row of data in memory already.
That does not sound right to me. It is a hashed lookup so it
should be O(1). Unless the hashing function is bad and there are a
lot of collisions, the lookup time should not vary greatly with the
number of snapshots on hand.
I don't have the source code so I can't tell. Maybe the buckets are
quite large; I don't know. What I do know is that when I do a long-
run operation with the same EC and no "tricks", the thread seems to
spend a sizable percentage of the time comparing snapshots --
presumably for facilitating uniquing.
Comparing snapshots would not be for uniquing. Unique tests would be
some variation of snapshotDict.objectForKey(gid). If it is comparing
snapshots, it is as a result of you fetching objects already in memory
with a refreshing fetch (or maybe even a non-refreshing one, I don't
recall at the moment). It will also do this for updated objects in an
EC as part of save processing. I don't recall any other time when it
would be comparing snapshots.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
