Re: Eaten by the Tiger? Open Source WO is coming...

I haven't done time testing with AJRDatabase but I know in EOF joins were by 
far the most expensive operations.

We spent a lot of time hacking EOF to speed it up. Betch fetching faults 
helps a lot (which by the way I still have to implement in AJRDatabase), but 
joins were still very expensive.

I'd love to see AJRDatabase scream, particularly for the report type stuff 
that EOF was always bad at, but I think we need to stabalize it a little 
before we start tuning it.

-Mont


On 8/25/05, Pierce T. Wetter III <[email protected]> wrote:
> 
> 
> On Aug 24, 2005, at 2:46 PM, Alex Raftis wrote:
> 
> >
> > On Aug 23, 2005, at 7:29 PM, Pierce T. Wetter III wrote:
> >
> >
> >> EOF used NSArrays in EOEditingContext and in many of the
> >> internal structures, so it ended being order(N) or order(N^2) for
> >> many operations. Its ok for fetching 20 objects, but if you fetch
> >> 10000...
> >>
> >> You can see this in AJR in EOEditingContext when it has to see
> >> if it already has an object matching a given globalID, it has to
> >> scan an array.
> >>
> >> NSSets would scale better.
> >>
> >
> > Actually, NSSet would be useless, because you have to access
> > object's by global ID. NSSet only allows you to add objects, see if
> > an object exists, and iterate the objects. So, in this case, what
> > would help is to use NSDictionary's to access the objects, and this
> > is precisely what my EOEditingContext does. Only the public API's
> > use NSArray. For example, when you ask for the inserted objects,
> > you get back an NSArray, not the underlying NSDictionary. Yes, this
> > is a little cumbersome, but it allows us to match the EOF API,
> > which became an important consideration. Note that the array is
> > cached until the NSDictionary updates, after which point the array
> > has to be regenerated.
> >
> > BTW, as far as a concern for performance on object size, I've fetch
> > 100,000+ records from a DB and first object fetches (almost) as
> > fast as the last object. There's a slight degradation of
> > performance, since the underlying hash table gets pretty large, but
> > it's negligible. You'll only notice the slow town if you're closely
> > timing things.
> 
> Which makes AJR much superior to EOF, as I commented, since EOF
> uses NSArrays, and the last object is definitely not as fast as the
> first object.
> 
> I don't know where I got that AJR used NSArrays then, because I
> remember reading the header file for an EOEditingContext.h and seeing
> NSArray, and going "bummer" and moving on.
> 
> So I apologize, and I'm much happier with AJR now. :-)
> 
> Just out of curiousity, do you have any idea what the ratio of EOF
> overhead to database fetch time is? We found that it was 3x, that it
> took 3 times as long to fetch an object into EOF as it did to fetch
> raw rows from Frontbase. Some of that was building the objects
> (malloc, etc.) but a lot of it was registering the objects.
> 
> 
> Pierce
> 
> _______________________________________________
> WebObjects-talk mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-talk
>