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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 4 Feb 2022 08:00:13 +0100 (CET)
On Fri, 4 Feb 2022, Henrik Holst wrote:
> 23% of those for curl.se and 8% for google.com is due to Curl_compareheader,
> this looks like an internal only function and every single use inside curl
> is using string literals so we can replace them all with a compile time
> sizeof, if patches for this would be accepted then I would be happy to
> provide such.
Oh, yes I think that would be a fine improvement!
> Which leaves 53 strlen calls for curl.se and 490 for google.com, for curl.se
> these are probably "no issue" but still no idea where the 490 ones for
> google.com comes from (the traces only shows that strlen was called, not on
> which string it was called so the digging is a bit time consuming).
I suspect the reason for this difference might be the SAN name checks for the
server certificate, since those name checks (when built to use OpenSSL) are
done by curl code and the google.com servers have a rather large amount of
names to check. See lib/hostcheck.c:Curl_cert_hostcheck()
Date: Fri, 4 Feb 2022 08:00:13 +0100 (CET)
On Fri, 4 Feb 2022, Henrik Holst wrote:
> 23% of those for curl.se and 8% for google.com is due to Curl_compareheader,
> this looks like an internal only function and every single use inside curl
> is using string literals so we can replace them all with a compile time
> sizeof, if patches for this would be accepted then I would be happy to
> provide such.
Oh, yes I think that would be a fine improvement!
> Which leaves 53 strlen calls for curl.se and 490 for google.com, for curl.se
> these are probably "no issue" but still no idea where the 490 ones for
> google.com comes from (the traces only shows that strlen was called, not on
> which string it was called so the digging is a bit time consuming).
I suspect the reason for this difference might be the SAN name checks for the
server certificate, since those name checks (when built to use OpenSSL) are
done by curl code and the google.com servers have a rather large amount of
names to check. See lib/hostcheck.c:Curl_cert_hostcheck()
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-04