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!
-
At 05:27 PM 12/1/2002 -0500, Sterling Hughes wrote:
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()
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
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.
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
How does searching the freelist work in this? How is this faster than
say a 3-level page table implementation?
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
On Saturday, November 30, 2002, at 07:17 PM, Sterling Hughes wrote:
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
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
A little off-list discussion has sold me on the linked list
implementation. Seems very fast and very simple.
George
On Saturday, November 30, 2002, at 07:53 PM, Daniel Cowgill wrote:
On Saturday, November 30, 2002, at 07:17 PM, Sterling Hughes wrote:
The problem I see with an array
On Sat, 30 Nov 2002, George Schlossnagle wrote:
A little off-list discussion has sold me on the linked list
implementation. Seems very fast and very simple.
O(1) operations are hard to beat. Note that free lists are
not primarily about speed, they are also an extremely helpful
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
11 matches
Mail list logo
