> At 07:17 PM 11/30/2002 -0500, Sterling Hughes wrote: > >hrm. :) > > > >My only question is really about sequential accesses. for the purpose of > >example > >let's pretend its just for zvals... > > > >(pool is our pool array of zval structs) > >ALLOC_ZVAL() > > -> Do we have a zval available? > > -> yes! > > -> return pool[0][0] > > > >ALLOC_ZVAL() > >... > > -> return pool[0][1] > > > >ALLOC_ZVAL() > >... > > -> return pool[0][2] > > > >FREE_ZVAL() > > -> Clear memory @ pool[0][1] > > > >ALLOC_ZVAL() > > -> Do we have a zval available? > > -> return pool[0][3] or do we return pool[0][1] > > > >The problem I see with an array approach from an api perspective is simply > >when a bucket > >is free'd, in order to have efficient memory usage, we'd need a second > >level array scan > >for every ALLOC_ZVAL(). > > > >Perhaps a linked list would be a better choice for this, as we can just be > >smart about bucket > >access, and eliminate the need for a scan (could be possible I'm missing > >something?) > > I think I was misunderstood. Of course I would want a free list. > Check out the objects_store code in ZE2. The idea is to have something > similar. When we free allocated buckets we add them to a linked list. The > linked list is inside the structure itself, i.e., when the bucket isn't > used we can use its memory for the pointer to the next element. So > allocation just takes the bucket out of the free list. So basically the > bucket is a union between sizeof(zval) and sizeof(*) (or sizeof(int)). > If it's still not clear I can explain it in a longer letter later on. >
Ok, i understand - you basically are doing the linked list approach, but using a two-tiered storage paradigm to avoid fragmentation? My only thought now is the dirty specifics: 1) Thread-safety: Will we have to mutex access to this cache? We shouldn't get corruption (I'd assume that on threaded environments we'd use a shared cache) if we have multiple accesses, and if we mutex, we might as well malloc(). 2) Growing buffer sizes. Say we have a _really_ intensive script that does make us grow our zval/object/hashtable cache substantially, however, it is run once every blue moon. Do we after execution is finished than realloc() that huge buffer back down to a normal size? Or perhaps we should just malloc() after a certain size is reached (ok, 16k of prealloc'd stuff, if we don't have a free slot, just do uncached mallocs). -Sterling -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
