Bob Rogers <[EMAIL PROTECTED]> wrote:
> This patch adds deletion to the same case. Testing also caught a
> missing label in the original version, for a branch that was never
> taken.
Thanks, applied - 8175
leo
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 16:58:00 +0200
Bob Rogers wrote:
> Below please find an additional test case for t/pmc/hash.t that defines
>
>>50K keys, while checking that earlier entries are still present. This
>
> takes about 0.8 sec
Leopold Toetsch wrote:
I'm currently rewriting the hash implementation in src/hash.c. The new
hash structure has just one piece of malloced memory with bucket
pointers and buckets in one piece.
The code is committed now, tests are passing as before the test.
leo
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 16:58:00 +0200
Bob Rogers wrote:
> Below please find an additional test case for t/pmc/hash.t that defines
>
>>50K keys, while checking that earlier entries are still present. This
>
> takes about 0.8 sec
> "BR" == Bob Rogers <[EMAIL PROTECTED]> writes:
BR>Uri Guttman wrote:
>> here is an odd thought to add to that. since your hash is a single hunk
>> of ram, you could use offsets inside it instead of pointers. that means
>> it could be both shareable (given locks) and even writabl
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman wrote:
>>> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> I'm currently rewriting the hash implementation in
>> src/hash.c. The
LT> new hash structure has just one piece of malloced memory with
LT> b
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 17:07:48 +0200
Bob Rogers wrote:
> + I22 = 5
> + set_multiple_keys(P30, I22, I29, I22)
> + print_multiple_keys(P30, I29, I30, I20)
> + print_multiple_keys(P30, I21, I30, I20)
Bob Rogers wrote:
+ I22 = 5
+ set_multiple_keys(P30, I22, I29, I22)
+ print_multiple_keys(P30, I29, I30, I20)
+ print_multiple_keys(P30, I21, I30, I20)
^^^
c&p typo
Small reminder: always "make test" before submitting patches
Thank
Bob Rogers wrote:
Below please find an additional test case for t/pmc/hash.t that defines
50K keys, while checking that earlier entries are still present. This
takes about 0.8 sec on my 1.8GHz AMD box, tunable by increasing I22. Is
this the sort of thing you had in mind?
Yeah. Thanks. It
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Fri, 20 May 2005 16:07:10 +0200
I'm currently rewriting the hash implementation in src/hash.c. The new
hash structure has just one piece of malloced memory with bucket
pointers and buckets in one piece.
But before comitting I'd l
Uri Guttman wrote:
"LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> I'm currently rewriting the hash implementation in src/hash.c. The
LT> new hash structure has just one piece of malloced memory with
LT> bucket pointers and buckets in one piece.
here is an odd thought to add to that.
Leopold Toetsch wrote:
I'm currently rewriting the hash implementation in src/hash.c. The new
hash structure has just one piece of malloced memory with bucket
pointers and buckets in one piece.
But before comitting I'd like to have some stress and benchmarks tests
that first show that my implem
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> I'm currently rewriting the hash implementation in src/hash.c. The
LT> new hash structure has just one piece of malloced memory with
LT> bucket pointers and buckets in one piece.
here is an odd thought to add to that. since your
I'm currently rewriting the hash implementation in src/hash.c. The new
hash structure has just one piece of malloced memory with bucket
pointers and buckets in one piece.
But before comitting I'd like to have some stress and benchmarks tests
that first show that my implementation is correct and
14 matches
Mail list logo
