Hacker News Reader

Comment by pekk | Hacker News Reader

"Premature" means "before measuring"

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.

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.

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.

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.

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).

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 [2] http://programmers.stackexchange.com/a/34788

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.

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.

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.

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.

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.

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).

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.

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.

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.

and "before defining acceptance criteria"

Reply on news.ycombinator.com