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: James Read via curl-library <>
Date: Thu, 27 Jan 2022 11:55:39 +0000

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