-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 6/16/2009 9:05 AM:
> I'd also like to squash this on, to fix grammar and provide some
> clarification. In particular, m4 uses the idiom of deleting elements during
> traversal, which is provably safe under certain conditio
Eric Blake wrote:
> + /* Guarantee that once we start moving entries into the new table,
> + we will not need any further memory allocations. We only need
> + new allocations if the hasher consolidates multiple buckets from
> + the old size into one bucket with the new size (a sign of
Eric Blake byu.net> writes:
> Indeed, if you are frequently calling allocate_entry, the cost of malloc'ing
> lots of small objects is measurably worse than using an obstack to malloc
large
> chunks and carve off entries as needed. In other words, it's not the speedup
> from freeing multiple
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
...
> My code inspection didn't turn up obvious problems, but I have not yet tested
> with USE_OBSTACK either, so I wouldn't be surprised to find bit rot. If we do
> get it working, would it be worth making the use of obstacks a runtime
> de
Eric Blake writes:
> There might also be alternative implementations possible with
> better performance. For example, instead of malloc'ing free
> entries one at a time and tracking bucket overflows as pointers
> to malloc'd objects, we could instead malloc/realloc an array
> of overflows, with
Jim Meyering meyering.net> writes:
> Long ago (like 12-15 years), in an application that made very heavy use
> of hash tables, the obstack code provided a large performance benefit.
Indeed, if you are frequently calling allocate_entry, the cost of malloc'ing
lots of small objects is measurably
Eric Blake wrote:
> Eric Blake byu.net> writes:
>> Subject: [PATCH] hash: improve memory management
>>
>> * lib/hash.c (hash_delete): Free entries if resize failed.
>> (hash_insert): Don't leave entry on table when returning failure.
>> (hash_rehash): Avoid memory leak, by guaranteeing that we won
Eric Blake byu.net> writes:
> Subject: [PATCH] hash: improve memory management
>
> * lib/hash.c (hash_delete): Free entries if resize failed.
> (hash_insert): Don't leave entry on table when returning failure.
> (hash_rehash): Avoid memory leak, by guaranteeing that we won't
> allocate once we s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 6/15/2009 5:17 PM:
>>> Additionally, it looks like hash_rehash has a memory leak - if new_table
>>> is allocated, but we later fail to allocate new_entry, the function
>>> returns immediately without reclaiming new_table. Wh
Jim Meyering meyering.net> writes:
> >> We should fix this, and decide whether shrinking the hash table when
> >> deletion frees up a bucket is always possible, or else deal with memory
> >> allocation failure here, too.
> >
> > Additionally, it looks like hash_rehash has a memory leak - if new_t
Eric Blake wrote:
> According to Eric Blake on 6/7/2009 9:51 PM:
>> According to Jim Meyering on 6/6/2009 2:41 PM:
>>> A few of the function declarations in hash.h could benefit from
>>> gcc's warn_unused_result attribute, so I'm adding it:
>>
>> Including one in hash.c itself:
>>
>> hash.c: In fu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 6/7/2009 9:51 PM:
> According to Jim Meyering on 6/6/2009 2:41 PM:
>> A few of the function declarations in hash.h could benefit from
>> gcc's warn_unused_result attribute, so I'm adding it:
>
> Including one in hash.c itsel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/6/2009 2:41 PM:
> A few of the function declarations in hash.h could benefit from
> gcc's warn_unused_result attribute, so I'm adding it:
Including one in hash.c itself:
hash.c: In function `hash_delete':
hash.c:1015: w
13 matches
Mail list logo
