On Tue, 10 Apr 2007, Robert Iakobashvili wrote:

> AREA/CLASS/EXAMPLE AFFECTED:
> Optimization of function curl_multi_socket()

A noticable effect is that it adds a new function to the API. Can you also
please provide a patch for the man page for this new function?

I appreciate your effort and contribution. I feel a bit silly for not having
done this optimization myself already in the past, as I consider it a fine and
straight-forward approach. Indeed good work!

> +#define CSELECT_IN 0x01
> +#define CSELECT_OUT 0x02
> +#define CSELECT_ERR 0x04

Please modify these to get a CURL_ prefix to stay within our scope.

> +CURL_EXTERN CURLMcode curl_multi_socket_noselect(CURLM *multi_handle,
> curl_socket_t s,
> + int bitset, int
> *running_handles);

I'm not very happy with the name for this new function. 'noselect' is not
really what I think about when we pass in "socket action bits" to avoid a
function call that is in fact rarely select()... Perhaps we should rather call
it curl_multi_socket_action() ? I'm open for further ideas.

> The performance improved a bit and the loader made 15% more requests for the
> same time.

Wow, that's certainly a significant improvement!

> - Is it better to add the bitmask to an exiting API curl_multi_socket()
> or for backward comp better to arrange another API like
> curl_multi_socket_noselect()?

The latter, apart from me not like the name then. :-) We should also already
now mark curl_multi_socket() as deprecated. Possibly we should even add a
macro for the public header file that makes recompiles use the new function.

> - Where to keep the bitmask: in SessionHandle or better in UserDefined?

Shouldn't it be located in the connectdata struct? If it should be in the
SessionHandle struct, it probably belongs in the 'UrlState' sub-struct.

> - Does it makes sense to have a flag and not to scan for all splay timers in
> multi_socket () every time, when calling e.g. curl_multi_socket_noselect() ?

How would that work? I mean, how can the app know when the timeout handling
can or should be skipped?

It doesn't really "scan for all", in the vast majority of all invokes it'll
detect that the root node has time left until expiry so it'll stop there.

> 1. A registered socket callback is called by libcurl on a connected handle
> after the state DONE. Thus, the hipev.c example registeres fd with libevent
> only for data read/write actions. Can it be done earlier just after
> non-blocking connect () in order to make more usage of epoll() and less of
> poll ()?

Yes sure, it certainly can be made to. It was just me taking the slightly
easier approach and focusing on the transfer phase.

> 2. There is a huge number of gettimeofday() calls originating from libcurl.
> What are the directions to decrease the numbers somehow?

I think the reason for them is that we call Curl_tvnow() at numerous places to
figure out how long time that has elapsed since the beginning (or at least
since a given time stamp in the past).

If we can figure out a way to perhaps make one call at an earlier place and
re-use the timevalue after that, we should be able to reduce some calls. If we
can figure out a way to know the time without calling gettimeofday() at all,
that would be even better.

Oh, perhaps not totally unimportant: I would like to apply this work after the
upcoming 7.16.2 release, which I should be able to ship "any day now"...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html