curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Fewer mallocs is better, episode #47

From: Henrik Holst via curl-library <>
Date: Thu, 27 Jan 2022 13:06:21 +0100

I wonder if the results that you see from that example is due to the short
life of each connection, aka most of the time there is spent on the
tcp-handshake (and possible the tls handshake on top of it all) combined
with a small initial tcp window that never gets large enough before the
page has been downloaded in full.

I have personally no experience pushing curl to its bw limits (I have no
such use case) but I do use epoll for raw tcp/ip solutions where I easily
push Gbps per connection but that is for very long lived connections (days
and months) so a whole different ballpark.

Try to download a much larger file than just the front page and see if that
changes things.


Den tors 27 jan. 2022 kl 12:55 skrev James Read <>:

> On Thu, Jan 27, 2022 at 11:48 AM Henrik Holst via curl-library <
>> wrote:
>> depends on architecture, AFAIK if you compile for 64-bit Windows then
>> __fastcall is completely ignored since the MS compiler uses the "Microsoft
>> x64 calling convention" there regardless of what one types according to
>> /HH
>> Den tors 27 jan. 2022 kl 12:40 skrev Gisle Vanem via curl-library <
>>> Henrik Holst wrote:
>>> > strlen() is one clear candidate for some optimizations, often however
>>> it is declared as __attribute_pure__ so the
>>> Another candidate for MSVC would be 'cl -Gr'.
>>> (build for fastcalls internally). But that's not
>>> possible now due to things like:
>>> cookie.c(1433): error C2440: 'function':
>>> cannot convert from 'int (__fastcall *)(const void *,const void *)'
>>> to '_CoreCrtNonSecureSearchSortCompareFunction'
>>> It would be interesting to compare the speed of
>>> a '__cdecl' vs '__fastcall' libcurl.dll.
> Just my two cents worth. But while we're talking about optimizations it
> seems to me that cURL project needs to work on optimizing bandwidth usage
> above all else. My experiments with cURL with epoll show that there is
> little to no performance gain when using above 1024 concurrent connections.
> This is not strictly a cURL only issue however as my experiments without
> cURL have shown the same results.
> It seems to me that we need to work on saturating available bandwidth
> above all else as this is the true hardware bottleneck.
> James Read
>> --
>>> --gv
>>> --
>>> Unsubscribe:
>>> Etiquette:
>> --
>> Unsubscribe:
>> Etiquette:

Received on 2022-01-27