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.

/HH

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

> 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: 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

Reply via email to