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: Timothe Litt <litt_at_acm.org>
Date: Thu, 27 Jan 2022 06:27:01 -0500
On 27-Jan-22 05:59, Henrik Holst wrote:
> 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.
>
Yes - but note that __attribute__((pure)) is a GNU extension (though
adopted by some others). You still end up with one call; when sizeof
can be substituted the result is none. And unless a function using
strlen on an argument is inlined, it won't help as much as using
sizeof() if the function is sometimes called with a constant and other
times with a non-constant.
Before embarking on any optimization project - especially
micro-optimizations - the potential performance gains should be
analyzed. If they're not significant, trading effort (and sometimes
code clarity/maintainability) is not worthwhile.
For a project like cURL, which is used on a wide range of platforms and
compilers (old and new), it's fine to exploit available extensions, but
care is needed before assuming they are present.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
> /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
>
Received on 2022-01-27
Date: Thu, 27 Jan 2022 06:27:01 -0500
On 27-Jan-22 05:59, Henrik Holst wrote:
> 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.
>
Yes - but note that __attribute__((pure)) is a GNU extension (though
adopted by some others). You still end up with one call; when sizeof
can be substituted the result is none. And unless a function using
strlen on an argument is inlined, it won't help as much as using
sizeof() if the function is sometimes called with a constant and other
times with a non-constant.
Before embarking on any optimization project - especially
micro-optimizations - the potential performance gains should be
analyzed. If they're not significant, trading effort (and sometimes
code clarity/maintainability) is not worthwhile.
For a project like cURL, which is used on a wide range of platforms and
compilers (old and new), it's fine to exploit available extensions, but
care is needed before assuming they are present.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
> /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.html
- application/pgp-signature attachment: OpenPGP digital signature