2008/5/7, Christopher Palow wrote:

> I will get to it this week sorry just a little busy today.

<joke mode on> Busy looping, perhaps ? <joke mode off>

That's fine, this will also give others the opportunity to jump in and
contribute something if they wish to.

> Let me know if you still want a .patch.

Obviously the patch that I was previously requesting to be resent by
you as a file attachment no. Its no longer needed. But if you do some
additional work and you feel like contributing with it, it would be
nice if you send it as a file attachment. Your busy looping issue
remains open or in unknown state.

And now going back to the topic... Well, more or less... And just in
case someone is still reading this thread ;-)

Now that the keys of the splay have microsecond resolution, the chance
of duplicate keys is dramatically reduced. This affects performance at
least from a theoretical point of view.

When there is a _big_ number N1 of nodes in the splay, all of them
with different keys, and the splay tree is being splayed a _big_number
N2 of times, the cpu time used to complete the N2 operations will be
greater than the one used to complete the same N2 operations on a
splay tree with the same N1 number of nodes but with a certain degree
of duplicate keys.

I know my above statement is theoretical and I have no numbers to
prove it, but given the splay code we are using I think the above is
true. We, obviously, here, for libcurl, would only care about which is
the big N2 number that makes a real and mensurable difference in cpu
time between using duplicate keys or not.

And I'm mentioning all this because we actually have the option to use
a certain degree of duplicate keys. Even when the underlying variable
used to hold the key is capable of microsecond resolution we could
choose to only use and store resolution in hundreds or tens of
milliseconds.

From a practical and general point of view I think that there is no
real need to use a resolution greater than tens of milliseconds for
libcurl's internal splay keys.

But it is also true that I have no idea of how big would be the N2
number of nodes in the splay needed to make any real difference for
libcurl. 1K, 10K 1000K simultaneous connections using the multi
interface ?

-- 
-=[Yang]=-