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

>
> OK, here's a little about how EOF does work. In EOF, the editing  
> context does in fact use NSMutableSet for it's backing store. Yes,  
> the method -insertedObjects, -updatedObjects, and -deletedObjects  
> return an NSArray, but the array is only constructed (and cached)  
> when the above calls to those methods are made. So, EOF will not  
> inherently slow down as more objects are fetched into the editing  
> context.

  Uh, that's just not true. There are several operations in EOF that  
scale (N^2) instead of N or N log N.

>
> However, both EOF and AJRDatabase make use of an optimization for  
> objects that have integer (or long) primary keys. For EOF, they  
> have a class called _EOIntegralPrimaryKey and AJRDatabase has a  
> class called EONumericGlobalID. Yeah, they're different, but very  
> low level and not used by the high level API's. The idea behind  
> both these classes is that you can created a faster, more efficient  
> global ID for objects that basically use an integer as their  
> primary keys. Since in DB design, the vast majority of tables do  
> use integers for their primary keys, this works out pretty well.
>
> However, there's a problem with this. If you insert 100,000 (this  
> was my test case) objects into a hash table (at least Apple's hash  
> tables) where the hash function is basically linear, you'll find  
> that performance serious begins to degrade. It appears that what  
> happens is that very few buckets in the hash table are used, which  
> basically results in a hash table with performance not all that  
> much better than an array.

  I've run into hash collision problems with EOF as well, even  
without using integer keys, sure. But I've also observed other  
slowdowns in EOF. Using sampler, I've found that EOF is using  
NSArrays where it shouldn't, no ifs, ands or buts. Yes, the global  
ids are registered in an NSHashTable, but most of the other objects  
are stored in NSArrays, and not just because that's what the APIs  
return; they actually do the set operations with NSArrays.

>
> As a final note, this code will need to be updated a little bit  
> once AJRDatabase supports full multithreading, since the key is  
> relying on the behavior of random number generators to produce the  
> same series of pseudo random numbers given the same initial seed.  
> The problem, of course, is that if another thread calls random()  
> between my call to srandom() and random(), we'll be one or more  
> values down the sequence and thus won't produce the same hash key.

   Have you seen the new @synchronize() keyword in ObjC?

   Pierce