Re: Which way is more efficient to get particular EOEnterpriseObject
Re: Which way is more efficient to get particular EOEnterpriseObject
- Subject: Re: Which way is more efficient to get particular EOEnterpriseObject
- From: Miguel Arroz <email@hidden>
- Date: Thu, 16 Aug 2007 10:46:58 +0100
Hi!
On 2007/08/16, at 05:12, Gennady Kushnir wrote:
Only for that HUUGE arrays? I thowght, that caching of objects,
that EOF
do shoud significally speed up fetches... Will it do real database
roundtrip for fetching an object that's already cached in memory?
(I know
it is, as it is in that array in relationship attribute)
Every fetch specification you do is a round-trip to the DB
(actually, a SELECT command). EOF may, or not, load individual
objects from the DB to memory as the result of a fetch spec. But it
will always ask the DB what are the objects that are the result of
the SELECT command. The cache acts this way: if you do a fetch spec,
and the resulting objects are ids 3, 4, 7 and 9, and you already have
3 and 7 in memory, EOF will only load 4 and 9.
100 objects is OK, but for big arrays, I find it difficult to
manage them with EOF without suffering from the performance hit. Even
if you addObjectToBothSideOfRelationship, EOF must load all the
objects in memory just to check it the object you are adding is
already there. A nice way to solve this is to not model the "to-many"
relationship, only the "to-one" reverse relationship.
And the other thing is: implement it in the easiest possible way, so
you don't waste resources on it and see whether it is actually too
slow. Never optimize anything that doesn't need optimization. Use the
simplest code you can write to get the job done and optimize only, if
that is too slow. Developer time is normally much more expensive than
CPU time.
Thank you for that advice, I'll take it into accont ))
In fact when I'm trying to "opimise" I optimise both CPU and developer
time. In this particut=lar case - it would be much easier to utilise a
structured hashtable than to write a cycle or qualifier each time I
mant
to get something from that unstructured array.
Thank you all who replied.
I think I'll buld a hashtable on demand (when this kind of query
is first
required).
That won't work, because, as you said, you might add and remove
objects from the relationship. The biggest problem in doing this is
not doing the code to build the hashtable. That's the easy part. The
hard part is maintaining the hashtable consistent with the array, as
it changes.
Yours
Miguel Arroz
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden