curl-library
RE: new function
Date: Sat, 25 Aug 2001 13:22:03 -0700
Hi all,
I've noticed a few emails recently regarding adding additional functions to minimize setup time by re-using or duplicating existing
session handles, etc.
My 2c is the amount of time it takes to set those options pales in comparison to how long it actually initiate a session and
transfer data over the net (even a lan). I've played with a multithreaded CURL program that beat apache into the ground with 100
simultaneous threads that handled thousands of url's per second on an old PII 233.
To put it another way, I'm not sure that adding this functionality would result in even a 1% improvement in performance. The vast
majority of the time is spent in opening up a new socket and doing network I/O, which you can't really avoid as I think each thread
needs its own socket.
Of course, I may just be full of it. Comments?
Lucas.
-----Original Message-----
From: curl-library-admin_at_lists.sourceforge.net
[mailto:curl-library-admin_at_lists.sourceforge.net]On Behalf Of Daniel
Stenberg
Sent: Friday, August 24, 2001 2:07 AM
To: T. Bharath
Cc: libcurl Mailing list
Subject: Re: new function
On Fri, 24 Aug 2001, T. Bharath wrote:
> Do you think it is possible to introduce a newfunction lets say CURL*
> curl_easy_duphandle(CURL* handle) which basically creates another handle
> with the same options as the handle being passed.
It would certainly be possible.
> The functionality would be similar to calling curl_easy_init and then
> again calling curl_easy_setopt but this would be much faster rather than
> again going through all the steps. The performance would be better than
> having a client side function which does the same thing(avoids the
> overhead of some many functions)
The question would be when you'd use it. I can only think of it as useful if
you have a multithreaded application and you run curl_easy_duphandle() for
each new thread to avoid a series of identical curl_easy_setopt() invokes in
every thread.
Or?
> Internally maybe you could have control over the data structures that
> should not be duplicated.
Oh yes, we should probably re-arrange the internal structure then so that we
can more easily keep track of what data that should be duplicated and how.
Duplicating a handle could only be a matter of cloning data and options,
internal state info and things like persistant connections cannot be
transfered.
-- Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/Received on 2001-08-25