Re: Fewer mallocs is better, episode #47

From: Timothe Litt <litt_at_acm.org>
Date: Thu, 27 Jan 2022 09:52:16 -0500

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.

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Received on 2022-01-27