Yeah, speaking of small gains, most optimizations like using ++i instead of i++ will gain less than one-thousandth a second. Actually, much less. This is only a must if you're looking at the performance critical loop that iterates so often that you notice.

However, it seems the OP is more interested in best practices. Writing overall better code I think is worth it, so long as you don't constantly refactor.

Quote:Original post by Decrius
I'm not too familiar with ASM, but I can read it a bit. Exporting the ASM sources sounds like a solid idea...using Release mode and the optimizations I'd use when I'd distribute it...

Two tips:
First, do not allow your compiler to inline functions when you look at asm. This makes it so you'll know where to look. While this isn't exactly a realistic condition, it just lets you see what the code looks like. Alternatively, with gcc, I can do inline assembly like so: asm("# comment"); and when I compile with -S, I can see exactly where the function is implemented. (There are ways to have g++ print the source and assembly together, but I find the assembly gets mangled so I rely on my own methods.)

Second, know that compilers don't do the obvious thing. For example, try dividing by seven. So, what you look at might not be clear at all. But, if you post here, I think we can help make sense of assembly.

On the increment thing: I think some compilers can tell how to increment i even if it's not an integer or a pointer. And i++ is sometimes actually faster according to the optimization guide I linked. It says that the cpu needs the address of the variable it's going to load so many cycles ahead of time, so i++ will be faster when loading from memory because the address can already be calculated.

    x = array[i++]

is faster than

    x = array[++i]

I think it's best to use ++i most of the time just so you KNOW it's optimized, but it sounds like speed(i++) CAN be greater than speed(++i).

Quote:Original post by Splinter of Chaos
I think it's best to use ++i most of the time just so you KNOW it's optimized, but it sounds like speed(i++) CAN be greater than speed(++i).

That brings up the major argument against hand-optimising this sort of thing - it is darn complicated, and results in little gain. The optimisations which can give incredible performance increases involve careful cache, memory and I/O management - you might save 10-50 cycles with clever assembly tricks, but a single cache miss costs you hundreds of cycles, and a page fault or I/O operation cost millions.

Thanks guys, great replies. I guess in the land of optimization, ASM is king :). Might be handy to learn ASM any time soon :)

And yes, I agree. Micro-optimizations is really for the hobbyist, it's really insignificant in regular programs, and can be misleading. It's difficult to say if things are faster or slower micro-wise, if you don't test it.

I want to test some algorithms as well though, so this'll come in handy :)

I currently use the Code Profiler that ships with CodeBlocks (which is the gcc one?). It looks a bit limited information-wise, any suggestions for a decent code profiler?

Quote:Original post by Decrius
I currently use the Code Profiler that ships with CodeBlocks (which is the gcc one?). It looks a bit limited information-wise, any suggestions for a decent code profiler?

Would that be gperf? Like all things gnu, it is quite powerful, but it takes a lot of getting used to. Give the documentation a thorough browser, or get yourself a graphical profiler.

Doesn't the C++ standard allow i++ to optimise out the returned value if it is not used, even for overloaded operators? For example, this would allow i++ in a for loop to not generate an unused temporary return if i is an iterator. I'm sure that all sensible compilers do this, in which case i++ or ++i would do exactly the same thing in a loop situation. However, I guess ++i is certain to be optimal - it's a minor point I think though.

Also, to emphasise, always profile and optimise the most time consuming functions. Anything else is simply a waste of time. Why get a 0.001% improvement when you could get a 30% improvement for the same effort?

Quote:Original post by AshleysBrain
Doesn't the C++ standard allow i++ to optimise out the returned value if it is not used, even for overloaded operators? For example, this would allow i++ in a for loop to not generate an unused temporary return if i is an iterator. I'm sure that all sensible compilers do this, in which case i++ or ++i would do exactly the same thing in a loop situation.

What if ++i and i++ are overloaded to do entirely different things? Despite the expectation that they represent pre and post-increment, the programmer is allowed to overload them to do whatever he wants: ++i could create a database, and i++ reformat your hard drive, for all the compiler knows.

Quote:Original post by swiftcoder
What if ++i and i++ are overloaded to do entirely different things? Despite the expectation that they represent pre and post-increment, the programmer is allowed to overload them to do whatever he wants: ++i could create a database, and i++ reformat your hard drive, for all the compiler knows.

You'd be crazy if you made those operators do different things! Surely an absolute recipe for disaster. Overloaded operators should do the obvious thing - ie. both increment overloads should increment the object in some way. If it's not obvious, a named function really should be used.

Anyway I can't remember where I read C++ allows removal of unused return temp values for i++ - does anyone know if that's allowed by the standard?

Quote:Original post by AshleysBrain

Quote:Original post by swiftcoder
What if ++i and i++ are overloaded to do entirely different things? Despite the expectation that they represent pre and post-increment, the programmer is allowed to overload them to do whatever he wants: ++i could create a database, and i++ reformat your hard drive, for all the compiler knows.

You'd be crazy if you made those operators do different things! Surely an absolute recipe for disaster. Overloaded operators should do the obvious thing - ie. both increment overloads should increment the object in some way. If it's not obvious, a named function really should be used.

OK, then by your logic, << and >> should only be used for bitshifts, right? Unfortunately, std::stream uses it for input/output. And what about boost::spirit, which overloads pretty much every operator in fairly unusual ways...

Quote:Original post by DevFred

Quote:Original post by Splinter of Chaos

    x = array[i++]

is faster than

    x = array[++i]

Be careful here, those two expressions have different semantics.

QFE