OK, We will try to recompile in blocking mode and will update you.
A little help:
In what source file is the concerned code?
How do you tell the compiler for which platform it should compile?
May get back to you if we are in troubles; before you leave us :) If we
don't, have wonderful vacation!

-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: Wednesday, June 26, 2002 11:41 AM
To: Guy Chemla
Cc: Curl Mailinglist
Subject: RE: cURL Performances

On Wed, 26 Jun 2002, Guy Chemla wrote:

> Command line for cURL:
> curl -o /dev/null http://10.200.1.14/test/test_1/index_[00-99].html
>
> Command line for wget:
> wget -O /dev/null -i list
> where list is
> http://10.200.1.14/test/test_1/index_00.html
> - - -
> http://10.200.1.14/test/test_1/index_99.html

Hm.

Okay, I can think of at least two ways in how this differs between curl and
wget. It would be really cool if you could somehow add some debug code to
figure out if any of these things is what matters here:

1. curl uses non-blocking sockets where wget uses blocking, so curl can
never
   hang waiting for more data where wget will do just that. This might make
   curl loop in the select() loop more often.

2. As a side-effect of the non-blocking sockets and a slightly bad
   implementation: when curl issues the HTTP-request, it loops until the
full
   request has been sent, instead of select()ing properly waiting for the
   socket to become "writable". This might take unnecessary CPU time.

Ok, just for the sake of it, I'll mention a few other differences too off
the
top of my head:

3. curl might be compiled IPv6 enabled which then makes it use different
name
   resolve functions. And if not IPv6-enabled, it still uses thread-safe
   versions that wget isn't. These diferences shouldn't matter at all.

4. curl uses HTTP 1.1 where wget uses HTTP 1.0. I can't figure out anything
   specific that would make 1.1 slower or more CPU demanding though (as
these
   documents aren't likely to be chunked-transfer encoded).

-- 
    Daniel Stenberg -- I'll be away for a month, starting tomorrow
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn