3 ms·

I don't entirely agree with this. There's a lot of low hanging fruit, especially in languages like C and C++, where a slight code modification can make a diffe

I don't entirely agree with this. There's a lot of low hanging fruit, especially in languages like C and C++, where a slight code modification can make a difference in run time, with zero impact on code readability. Here's one example: Using: size_t len = strlen(myString); for (int i=0; i<len; ++len) { ... } Over: for (int i=0; i<strlen(myString); ++len) { ... } The second for loop is potentially O(n^2) because strlen needs to scan the entire string every time through the loop, where the first for loop computes strlen once. It's possible the compiler can optimize so that only one strlen is used in the second case, but it's not guaranteed. Probably it doesn't matter, but it will start to slow down once this function is called with longer strings and/or inside tight loops. They're almost the same, so why ever use the slower one? And C++ is even worse with destructors and copy and move constructors being called all over the place for people who aren't careful.

lmm 12y ago
I don't think that's "zero impact on code readability" at all; the extra line and extra variable adds overhead when reading, all of which will add up over many maintenance cycles. And I do think it's "zero impact on performance" in any real program; even if the compiler didn't optimize, I'll bet that particular loop wouldn't even show up in your profiler.
- umanwizard 12y ago
  What makes you think it's zero impact on performance, necessarily? Any sort of parsing is normally CPU-bound if anything, and anytime you're lexing+parsing, you're iterating over characters in a string almost by definition.
matwood 12y ago
I would call using the first example good programming and not an optimization. Anytime a loop is involved it is simply good practice to limit calling anything multiple times unless absolutely necessary. A second reason the first is better is that it clearly conveys to the next programmer that there is no intention for myString to change length during the running of the loop. If I came across the second example I would wonder if the length of myString was changing in the loop.
richardwhiuk 12y ago
In most cases I expect the C compiler to hoist the strlen out of the loop (I don't know whether it will in practice, but the V8 compiler for Javascript will definitely make a similar harder optimization, so it doesn't seem unlikely).
- umanwizard 12y ago
  I just tested this with GCC (gcc -S test.c --std=c99) and it doesn't optimize out the strlen inside the loop if the string is a variable (even if defined by const char *foo = "constant string";). If you're calling strlen on a constant string directly, it is indeed smart enough to optimize it out.
  - eropple 12y ago
    This is the correct behavior. It's not like they're immutable strings, or even that the variable's guaranteed to be pointed at the same place on every iteration of the loop. (You could say that a sufficiently smart static analyzer should be able to do that...but that static analyzer better ask about that thread you're running over there...) Compilers have a limit to how smart they can be, and that totally makes being smart about your stuff all the more important.
    - umanwizard 12y ago
      As far as I understand, a string defined as const char * can be treated as immutable. Casting away a const qualifier and then modifying the referenced value is undefined behavior.

lmm 12y ago

I don't think that's "zero impact on code readability" at all; the extra line and extra variable adds overhead when reading, all of which will add up over many maintenance cycles. And I do think it's "zero impact on performance" in any real program; even if the compiler didn't optimize, I'll bet that particular loop wouldn't even show up in your profiler.

umanwizard 12y ago
What makes you think it's zero impact on performance, necessarily? Any sort of parsing is normally CPU-bound if anything, and anytime you're lexing+parsing, you're iterating over characters in a string almost by definition.

matwood 12y ago

I would call using the first example good programming and not an optimization. Anytime a loop is involved it is simply good practice to limit calling anything multiple times unless absolutely necessary. A second reason the first is better is that it clearly conveys to the next programmer that there is no intention for myString to change length during the running of the loop. If I came across the second example I would wonder if the length of myString was changing in the loop.

richardwhiuk 12y ago

In most cases I expect the C compiler to hoist the strlen out of the loop (I don't know whether it will in practice, but the V8 compiler for Javascript will definitely make a similar harder optimization, so it doesn't seem unlikely).

umanwizard 12y ago
I just tested this with GCC (gcc -S test.c --std=c99) and it doesn't optimize out the strlen inside the loop if the string is a variable (even if defined by const char *foo = "constant string";). If you're calling strlen on a constant string directly, it is indeed smart enough to optimize it out.
- eropple 12y ago
  This is the correct behavior. It's not like they're immutable strings, or even that the variable's guaranteed to be pointed at the same place on every iteration of the loop. (You could say that a sufficiently smart static analyzer should be able to do that...but that static analyzer better ask about that thread you're running over there...) Compilers have a limit to how smart they can be, and that totally makes being smart about your stuff all the more important.
  - umanwizard 12y ago
    As far as I understand, a string defined as const char * can be treated as immutable. Casting away a const qualifier and then modifying the referenced value is undefined behavior.