If this is the case, they're relatively cheap - the call overhead + an early check for NULL arg.
The 1 byte memcpy is worth a look. If it's copying null (zero-length) strings, the strlen work could allow replacement with a test/assignment. memcpy is not likely to be optimized for that case. It tends to be optimized for longer moves.
It would not be surprising if both are in openssl/nghttp2 rather than cURL proper.
You may be able to eliminate the clock_gettime calls if no one is looking at timing, which is probably a common case for library users. (For the command, !(verbose|progress|?timeouts?), but progress is a default.) They are relatively inexpensive syscalls, frequently optmized, but may involve a mode change and a lock (depending on architecture and OS). But you may need an API change (e.g. in global_init or setopt) to disable statistics.
In all three cases, look at the actual performance impact - the return on fixing these may be low.
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 14-Feb-22 03:33, Daniel Stenberg via curl-library wrote:
Other fun observations running this same command line: The top-25 lib calls done: 2239 free 635 malloc 545 memcpy 300 memchr 245 strcmp 225 strlen 162 inet_pton 134 clock_gettime 110 OPENSSL_sk_value 110 ASN1_STRING_length 110 ASN1_STRING_get0_data 75 strdup 63 sigaction 56 calloc 50 nghttp2_session_get_stream_user_data 38 realloc 37 ERR_clear_error 36 strchr 31 poll 31 nghttp2_session_want_read 28 nghttp2_session_send 26 nghttp2_session_mem_recv 26 nghttp2_session_check_request_allowed 25 getenv 24 SSL_set_ex_dataThose 545 memcpy() calls are interesting because 384 of them copy only a single byte!
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
