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: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 10 Feb 2022 19:23:11 +0100
Den lör 5 feb. 2022 kl 23:13 skrev Daniel Stenberg <daniel_at_haxx.se>:
> On Sat, 5 Feb 2022, Henrik Holst wrote:
>
> > Anyway, I will take a look at it first and then come back with more info
> and
> > you can all decide then if the proposed changes are too hard to read or
> > unusual, I have no problem doing some some work that in the end will be
> > rejected.
>
> I like that!
>
Further investigation shows that this will probably not yield much. Looks
like many of the hostname uses comes from the curl binary via glob_url so
there is not much we can do in libcurl to prevent these.
However I did find that an a normal run to fetch curl.se (or any site
really) this happens:
henrik_at_Sineya:~/utveckling/repositories$ uftrace -a -- ./curl/src/curl -Ls '
https://curl.se/' -o /dev/null | grep strlen | grep certs
0.251 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.140 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.140 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.160 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.150 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.210 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.141 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
7.244 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.250 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.231 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
Now the strlen itself here is not the problem, the problem is that
Curl_setstropt is called 10 times and Curl_clone_primary_ssl_config is
called 3 times for a single run. Now I don't know how much of this is done
by libcurl and how much of this is done by the curl binary but it could be
something that someone could have a look at, aka why the cert file option
is set over and over again for what should be a single easy handle.
I get it that strings have to be strdup:ed around since c/curl doesn't use
reference counted strings, but still when a single threaded case does 10
strdup:s of the same string something looks fishy (which is not to say that
it is fishy, just that it have a potential to be).
/HH
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>
Date: Thu, 10 Feb 2022 19:23:11 +0100
Den lör 5 feb. 2022 kl 23:13 skrev Daniel Stenberg <daniel_at_haxx.se>:
> On Sat, 5 Feb 2022, Henrik Holst wrote:
>
> > Anyway, I will take a look at it first and then come back with more info
> and
> > you can all decide then if the proposed changes are too hard to read or
> > unusual, I have no problem doing some some work that in the end will be
> > rejected.
>
> I like that!
>
Further investigation shows that this will probably not yield much. Looks
like many of the hostname uses comes from the curl binary via glob_url so
there is not much we can do in libcurl to prevent these.
However I did find that an a normal run to fetch curl.se (or any site
really) this happens:
henrik_at_Sineya:~/utveckling/repositories$ uftrace -a -- ./curl/src/curl -Ls '
https://curl.se/' -o /dev/null | grep strlen | grep certs
0.251 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.140 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.140 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.160 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.150 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.210 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.141 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
7.244 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.170 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.250 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
0.231 us [ 42540] |
strlen("/etc/ssl/certs/ca-certificates.crt") = 34;
Now the strlen itself here is not the problem, the problem is that
Curl_setstropt is called 10 times and Curl_clone_primary_ssl_config is
called 3 times for a single run. Now I don't know how much of this is done
by libcurl and how much of this is done by the curl binary but it could be
something that someone could have a look at, aka why the cert file option
is set over and over again for what should be a single easy handle.
I get it that strings have to be strdup:ed around since c/curl doesn't use
reference counted strings, but still when a single threaded case does 10
strdup:s of the same string something looks fishy (which is not to say that
it is fishy, just that it have a potential to be).
/HH
> --
>
> / 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-10