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@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.html