Re: [PATCHES RFC 2/2] Optional hash table improvements
Date: Wed, 2 May 2007 18:05:34 +0200
On 5/2/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 1 May 2007, Robert Iakobashvili wrote:
> hash_fd() is added as a library-wide symbol. If it should remain so, it should
> be Curl_ prefixed, but it seems to only be used from within multi.c so I
> suggested it is moved there and made static. What do you say?
> fd_key_compare seems to be in the same position.
I am used to keeping hash functions in some visible place, so that other
modules could use it when necessary, but no problems with keeping them
> > return ((fd < (int)slots_num) ? fd : fd % (int)slots_num);
> Is this complication really necessary? I mean, why not just do it:
> return fd % (int)slots_num;
No problems with both impementations
> > 2) curl-socket-hash-table-size.patch - is a very optional patch
> > improving the performance only above 10K curl handles;
> I figure upping that size is okay. Possibly we should consider a way to either
> let the app somehow set it or perhaps allow it to grow somehow. Of course we
> can even consider a different hash implementation that can deal with 10 or
> 10000 entries in a way that doesn't require us to change a fixed array size
> like this.
When it is an ifndef-ed define, one may overwrite it.
> I mean, if someone goes mad and tries 100,000 connections they probably will
> see that upping this size even more will be very beneficial to them...
Actually, we were really planning doing that in a couple of months...
and our madness is limited only by some more urgent features/issues and absence
of appropriate HW.
-- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ........................................................... http://curl-loader.sourceforge.net A web testing and traffic generation tool.Received on 2007-05-02