-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
Jim Meyering meyering.net> writes:
>
> 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
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
Jim Meyering meyering.net> writes:
> > 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. Which means that even
> > if an application is prepared to
Eric Blake byu.net> writes:
>
> I got bored and attempted this. This implementation still passes the m4
> testsuite, although there might be corner cases not exercised by m4 (such as
> shrinking the table on hash_delete) that I got wrong, so I'm posting it for
> review now. In particular, I
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
A few of the function declarations in hash.h could benefit from
gcc's warn_unused_result attribute, so I'm adding it:
>From 28e62601bcb5c76e7d4a24ef7d2faaf281503353 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 6 Jun 2009 22:39:23 +0200
Subject: [PATCH] hash: declare some f
17 matches
Mail list logo
