8 ms·

"Premature" means "before measuring"

by pekk 12y ago

kasey_junk 12y ago
and "before defining acceptance criteria"
eropple 12y ago
There are many optimizations that make sense to do "before measuring" because they're free and easy to do as a matter of habit. For example, the use of value types in C# is just as easy as classes--you just need to know how your runtime works and pick the correct allocation method. It takes me literally no time whatsoever to know intuitively that, yes, this should be a struct rather than a class. But I've seen developers dismiss this as "premature optimization" rather than knowing how my software works.
- chc 12y ago
  Can you quantify the % performance gains you've gotten from this on a given project? Because from what you've said here, it seems entirely possible you're not actually writing appreciably more performant code than they are. This is why the measuring is usually how you know how your software works.
  - mark-r 12y ago
    I think you missed the point of the parent comment. If there's two ways of doing the same thing, and one way is clearly more efficient, there's no reason not to do it the efficient way. Get in the habit, and you won't even waste brainpower thinking about it. 99% of the time it might not make a difference, but for that 1% you're ahead. You're also covered if a change somewhere else causes your code to be executed a lot more often than you expected it to be.
    - eropple 12y ago
      Agreed. Though, to answer your parent post: when helping friends with XNA or MonoGame projects, I've shaved entire milliseconds off of frame times (particularly notable when you have a 16ms budget) by removing needless reference types, either by unpacking and using primitives or by replacing those reference types with structs. Or, when I was at TripAdvisor, we (not me originally, though I inherited it) greatly improved typeahead performance by dropping the built-in collections classes (which used boxed primitives, because lolbrokengenerics) in favor of Trove (or Colt, I can't remember) and the reified primitive types. If I write Java today, I reach for Trove as a matter of course just because it means I never write List<Integer>. This stuff matters. Getting in the right habits is not hard and will pay off in the ten percent of cases where it matters.
  - grok2 12y ago
    The problem is that when the software works well, it's hard to attribute it to all the experience of the developer whose knowledge of what performance traps to avoid has helped the software. It is only when performance problem shows up that people actually notice things and measure things since it's worth measuring at that point. But there is still value to the experience based optimization steps developers use based on their prior experience with imilar software without any measurement (with the caveat that it doesn't complicate the software or make it hard to understand).
- jwmerrill 12y ago
  You have made the considerable investment required to learn a language that allows making such a distinction, and when to use which. Other people have spent that time doing other things, and yet they are still sometimes able to produce software that is valuable to themselves or others. One man's saw sharpening [1] is another man's yak shaving [2]. Personally, I like my saws very sharp, thank you very much, but I think it's important to also have sympathy for people with different backgrounds and priorities. [1] http://c2.com/cgi/wiki?SharpenTheSaw http://c2.com/cgi/wiki?SharpenTheSaw [2] http://programmers.stackexchange.com/a/34788 http://programmers.stackexchange.com/a/34788
- colordrops 12y ago
  If you already know one method is faster than another, then it is post-measurement, even if you measured it in a previous project, and thus not premature.
jlarocco 12y ago
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.

"Premature" means "before measuring"

by pekk 12y ago

"Premature" means "before measuring"

kasey_junk 12y ago

and "before defining acceptance criteria"

eropple 12y ago

There are many optimizations that make sense to do "before measuring" because they're free and easy to do as a matter of habit. For example, the use of value types in C# is just as easy as classes--you just need to know how your runtime works and pick the correct allocation method. It takes me literally no time whatsoever to know intuitively that, yes, this should be a struct rather than a class. But I've seen developers dismiss this as "premature optimization" rather than knowing how my software works.

chc 12y ago
Can you quantify the % performance gains you've gotten from this on a given project? Because from what you've said here, it seems entirely possible you're not actually writing appreciably more performant code than they are. This is why the measuring is usually how you know how your software works.
- mark-r 12y ago
  I think you missed the point of the parent comment. If there's two ways of doing the same thing, and one way is clearly more efficient, there's no reason not to do it the efficient way. Get in the habit, and you won't even waste brainpower thinking about it. 99% of the time it might not make a difference, but for that 1% you're ahead. You're also covered if a change somewhere else causes your code to be executed a lot more often than you expected it to be.
  - eropple 12y ago
    Agreed. Though, to answer your parent post: when helping friends with XNA or MonoGame projects, I've shaved entire milliseconds off of frame times (particularly notable when you have a 16ms budget) by removing needless reference types, either by unpacking and using primitives or by replacing those reference types with structs. Or, when I was at TripAdvisor, we (not me originally, though I inherited it) greatly improved typeahead performance by dropping the built-in collections classes (which used boxed primitives, because lolbrokengenerics) in favor of Trove (or Colt, I can't remember) and the reified primitive types. If I write Java today, I reach for Trove as a matter of course just because it means I never write List<Integer>. This stuff matters. Getting in the right habits is not hard and will pay off in the ten percent of cases where it matters.
- grok2 12y ago
  The problem is that when the software works well, it's hard to attribute it to all the experience of the developer whose knowledge of what performance traps to avoid has helped the software. It is only when performance problem shows up that people actually notice things and measure things since it's worth measuring at that point. But there is still value to the experience based optimization steps developers use based on their prior experience with imilar software without any measurement (with the caveat that it doesn't complicate the software or make it hard to understand).
jwmerrill 12y ago
You have made the considerable investment required to learn a language that allows making such a distinction, and when to use which. Other people have spent that time doing other things, and yet they are still sometimes able to produce software that is valuable to themselves or others. One man's saw sharpening [1] is another man's yak shaving [2]. Personally, I like my saws very sharp, thank you very much, but I think it's important to also have sympathy for people with different backgrounds and priorities. [1] http://c2.com/cgi/wiki?SharpenTheSaw http://c2.com/cgi/wiki?SharpenTheSaw [2] http://programmers.stackexchange.com/a/34788 http://programmers.stackexchange.com/a/34788
colordrops 12y ago
If you already know one method is faster than another, then it is post-measurement, even if you measured it in a previous project, and thus not premature.

jlarocco 12y ago

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.