Re: [PATCH] Preallocate hash tables when the number of inserts are known in advance

> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> This avoids unnecessary re-allocations and reinsertions. On webkit.git
>> (i.e. about 182k inserts to the name hash table), this reduces about
>> 100ms out of 3s user time.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> I think this is a very good idea, but I would prefer the second
> parameter to the "preallocate" to be "expected number of entries"
> and have the preallocate, which is a part of the hash API, decide
> how to inflate that number to adjust to the desired load factor of
> the hash table.  We shouldn't have to adjust the caller when the
> internal implementation of the hash table changes.

>> ---
>>  nd/read-directory-recursive-optim reduces the number of input (from
>>  182k to 11k on webkit) to exclude machinery that all patches in the
>>  exclude optimization series I posted seem insignificant. So I won't
>>  repost them for inclusion unless you think it has cleanup values.
>
> Sorry, without a pointer, it is unclear what "exclude optimization
> series" you are referring to.