curl / Mailing Lists / curl-library / Single Mail
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

From: Henrik Holst via curl-library <>
Date: Thu, 27 Jan 2022 11:59:15 +0100

sizeof have been a compile time constant since inception, however since C99
it can also be used on variable length arrays and for those it of course
have to be a runtime operation. Perhaps OpenLDAP used variable length
arrays to a huge degree?

strlen() is one clear candidate for some optimizations, often however it is
declared as __attribute_pure__ so the compiler should be smart enough to
remove redundant calls, but for constant strings a macro like "#define
BUFFER_COPY_STRING_CONST(x, y) buffer_copy_string_len(x, y, sizeof(y) - 1)"
is useful if curl have many such constant strings passed to various
functions that also needs the string length.


Den tors 27 jan. 2022 kl 11:52 skrev Timothe Litt via curl-library <>:

> On 27-Jan-22 04:27, Daniel Stenberg via curl-library wrote:
> On Thu, 27 Jan 2022, Gavin Henry wrote:
> I remember in the OpenLDAP project when they removed/reduced the amount of
> times sizeofs that were used for performance gains.
> When is sizeof ever a slow operation?
> As we're only using C89, our sizeof uses are only ever for types/structs,
> and I can't see how those are not just converted to a constant at
> compile-time by the compiler.
> I'm not familiar with the OpenLDAP exercise, but I also doubt that sizeof
> would be slow. Even really, really old, dumb compilers turn them into
> constants.
> 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...
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
> --
> Unsubscribe:
> Etiquette:

Received on 2022-01-27