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 00:59:50 +0100
Hi!
On 2007/08/16, at 00:25, Gennady Kushnir wrote:
- cycle through array (which I get from relationship attribute),
checking
if attributes match
Being a 100 elements array, I guess that's doable. CPUs are
screaming fast today, so even if you have to look-up the entire array
100 times (100 * 100) it should be still fast enough. If we are
taking tens of thousands of objects, it's more complicated.
- construct EOQualifier and filter the array with it
I think that's basically the same thing. EOQualifier will do the
same work.
- just fetch required object regarding mentioned relationship as
just one
of attributes involved
That will be really slow. This is only useful of the number of
objects you have to pick to build the page is much smaller than the
total number of objects in the array. Say you have 10k objects in the
array, and you need 50 objects to build the page. It's probably
faster to do the 50 queries to the DB than loading up all the 10k
objects and search them. Specially the "load 10k objects to memory"
is a really big performance hit.
- index that array converting it into actual multi-dimensional as
mentioned above (using pure Java multidimensional arrays or nesting
NSArrays/NSDictionaries)
That will give you the fastest performance, but it's a maintenance
hell. To the more experienced ones: is this even doable, in terms of
complexity? How to handle... you know... my dear concurrency? :) The
array being modified, merged, etc?
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