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: Fri, 28 Jan 2022 15:29:54 +0100
actually that was quite a lot more than I expected from a single fetch of a
14527 bytes page. Now I have no idea how many of those that OpenSSL
performed, but 686 calls to strlen for a fetch that yields 25 http headers
in total (for which strlen probably shouldn't be called even once) sounds
like quite a lot. Now of course the amount of time spent on strlen here is
dwarfed by the network time to fetch those 14527 bytes (not counting the
TLS overhead) but it does "waste" (depending on if they even can be reduced
and even then what the savings would be) cpu time for setting up new
connections for people like James that tries to handle thousands of
connections at once.
You are correct though that this is most likely not a case for concern for
the average user of curl/libcurl.
/HH
Den fre 28 jan. 2022 kl 15:00 skrev Daniel Stenberg via curl-library <
curl-library_at_lists.haxx.se>:
> On Thu, 27 Jan 2022, Gavin Henry via curl-library wrote:
>
> > Yes, it was strlen. My apologies. They switch to berval types:
>
> For the fun of it I checked curl's use of strlen in a typical invoke like
> shown before. "curl -Ls https://google.com/" (which includes a redirect)
>
> Counting all uses with ltrace, also including OpenSSL etc.
>
> It then makes around 686 calls to strlen(). The *total* size was 7826,
> thus
> the average call is for strings less than 12 bytes long. The longest
> returned
> value is 36 (*) The median length is 10.
>
> Conclusion: I'm not seeing a general strlen problem in curl.
>
> (*) = this is the longest SAN name returned in the server cert
>
> --
>
> / 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.html
>
Date: Fri, 28 Jan 2022 15:29:54 +0100
actually that was quite a lot more than I expected from a single fetch of a
14527 bytes page. Now I have no idea how many of those that OpenSSL
performed, but 686 calls to strlen for a fetch that yields 25 http headers
in total (for which strlen probably shouldn't be called even once) sounds
like quite a lot. Now of course the amount of time spent on strlen here is
dwarfed by the network time to fetch those 14527 bytes (not counting the
TLS overhead) but it does "waste" (depending on if they even can be reduced
and even then what the savings would be) cpu time for setting up new
connections for people like James that tries to handle thousands of
connections at once.
You are correct though that this is most likely not a case for concern for
the average user of curl/libcurl.
/HH
Den fre 28 jan. 2022 kl 15:00 skrev Daniel Stenberg via curl-library <
curl-library_at_lists.haxx.se>:
> On Thu, 27 Jan 2022, Gavin Henry via curl-library wrote:
>
> > Yes, it was strlen. My apologies. They switch to berval types:
>
> For the fun of it I checked curl's use of strlen in a typical invoke like
> shown before. "curl -Ls https://google.com/" (which includes a redirect)
>
> Counting all uses with ltrace, also including OpenSSL etc.
>
> It then makes around 686 calls to strlen(). The *total* size was 7826,
> thus
> the average call is for strings less than 12 bytes long. The longest
> returned
> value is 36 (*) The median length is 10.
>
> Conclusion: I'm not seeing a general strlen problem in curl.
>
> (*) = this is the longest SAN name returned in the server cert
>
> --
>
> / 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.html
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-28