On 27-Jan-22 06:25, Gavin Henry wrote:
Perhaps the win was from reducing strlen() calls? They are often overused, and while they can be optimized to some extent, they are inherently slow at runtime. Unless a compiler is smart enough to detect a string constant, where x is a constant replacing strlen(x) with (sizeof(x)-1) can be a win - which may have been what jogged this memory...Yes, it was strlen. My apologies. They switch to berval types:typedef struct berval { ber_len_t bv_len; char *bv_val; } BerValue, *BerVarray; https://www.openldap.org/software//man.cgi?query=ber_free&sektion=3&apropos=0&manpath=OpenLDAP+2.4-Release
All that's old is new again. String descriptors were common in the 70s - VMS being perhaps the most prominent OS that used them natively.
The descriptor provides an efficient strlen(), but also allows strings to contain \0.
On the current subject - the most efficient way to use this structure is to use a single malloc to hold both the structure and the string. You can preserve an API by copying nul-terminated input into one of these (which merges the strlen and the copy). And in that case, a further optimization is to remove the bv-val pointer and simply place the data there.
I'm not sure where cURL would get a big benefit from this - perhaps parsing HTTP headers, though one would hope that data transfer dominates.
As previously noted, performance profiling on real workloads will determine where time is spent. gprof (or your favorite tool) should be opened before the editor...
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
