On 22/09/2025 08:29, Yair Lenga via Gcc wrote:
Hi,
I've inherited an old code base of "C" code, which was maintained by
relatively inexperience team. One of the common pattern that I've seen was:
for (int i=0 ; i < strlen(s) ; i++) { ... }
Which has O(n^2) performance, given O(n) performance on s. Acceptable on
strings up to 400-500 characters, but painful when large strings - 4k.
My question: Is there a path to add new performance-related diagnostics for
those cases, in general, any function with expected O(n) in the
condition/step of a loop (for ; while ; do ... while) should trigger this
warning. The most common pattern that I've seen - I believe other pattern
also exists - with strchr, strstr, ...
Ideally, this will come with an annotation that can be placed on function
to say "I'm expensive, should not be called in a tight loop"
[[GNU:expensive]] const int count_something(const char *x) ;
which will result in a performance warning on
for (int i=0 ; i<count_something(s) ; i++)
Looking for feedback, and suggestion on how to get something like that
implement - is this something that will be useful ?
Yair
gcc (and most C libraries used with gcc) already has a solution for
making code such as your original pattern efficient. "strlen" is marked
with the attribute "pure", which tells gcc that the function has no
side-effects and it can therefore in many cases move the call to
strlen() outside the loop :
<https://godbolt.org/z/1r6sj3dnf>
I can understand that you feel it is poor practice to have the strlen
call inside the loop - not every compiler can optimise as well as gcc -
but I don't think it is easy to specify a warning such as you describe.
How should it distinguish between a tight loop that calls your
"expensive" function, and one that calls another function that happens
to contain the "expensive" function?
It would certainly make sense in a coding standard to say that the
limits in a for-loop should be calculated before the loop, but I suspect
it would be very difficult to have good automatic tests on that.