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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
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.
/HH
Den tors 27 jan. 2022 kl 11:52 skrev Timothe Litt via curl-library <
curl-library_at_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
>
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.
/HH
Den tors 27 jan. 2022 kl 11:52 skrev Timothe Litt via curl-library <
curl-library_at_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.htmlReceived on 2022-01-27