> At 02:59 PM 11/30/2002 -0500, Sterling Hughes wrote: > >Hey, > > > >I was checking the CVS logs, and I read :: > > > >revision 1.13 > >date: 2001/11/26 17:27:59; author: andi; state: Exp; lines: +1 -1 > >- Turn off fast cache until we make sure it performs well. > >- The best solution is probably to limit its size. > > > >I was just wondering what was wrong, and what it would take to > >get this thing up and running... Thies and I were looking at a > >little hack, similiar in nature to this, with preallocating a pool of > >zval's, and it yielded a 5% performance increase (all hacking credit > >goes to thies btw :). > > First of all, let me just say that I wouldn't be too excited about 5% > performance difference either way. I already told Thies that from my > experience 5% is within the error margin and can change according to > compile flags, platform and so on.
perhaps... this was 5% worse case though, comparing to similairly compiled source trees. In some cases it yielded 15-30% percent, but that can be as you say, attributed to flukes. Still, it would follow that having a memory cache would be a "good thing," even if it does only show 5% (on a small script btw)... > The reason why the fast cache didn't work well was because it created quite > a bit of memory fragmentation which killed MT servers and also made PHP > take up too much memory. > > >If we preallocated some basic, often used types, i think we'd get a > >nice performance increase, perhaps even if we initialized in sapi > >modes a few structures in MINIT, we could reuse those instead of > >creating and destroying which is currently quite expensive? > > That said, I do think that if we can get very fast code to pre-allocate > zval's it would be a good idea (hopefully we could get more than 5% > increase). > I already have an idea for how I would want such an API to look like and I > was planning to write it. It would also be useful for Zend objects which > are preallocated today but if a realloc() were to be reached it would take > quite some time (although one or two realloc()'s wouldn't be terrible). no it wouldn't, and you've also gotta look @ this in terms of what would cause a realloc(), for example, say we have a 16 k pool, hardly anything, and yet we'd need to have _a ton_ of concurrently allocated zvals in order to fill that up. Plus, while the realloc would be expensive, it would be better than doing that many mallocs. Anyhow, we pretty much agree, soooooo :) > My idea is a two dimensional array. We'd allocate 2^n of memory blocks and > assign it to array[0]. Once these are full we'd allocate another 2^n memory > blocks and realloc() array to size of 2 and make array[1] point to it. The > index to a block would be X and to find the right position it'd be > array[X/2^n][X%2^n] of course as the length of each array is a power of two > we wouldn't actually need to use division and modulo so it'd be fast. > As we don't have templates in C we might be able to put all of this inline > in a header file and with macros create such a fast allocating pool for > some of the most used types specifically I think it'd be useful for zval's, > objects and possible hash tables. I wouldn't overdo the amount of types I'd > add to this pool because unless they are allocated and freed extremely > often we wouldn't notice a speed difference. > > But remember what I said about 5% :) 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?) -Sterling -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
