Normally I am against early optimization, I think you should profile your code with the appropriate tools to find the real bottlenecks before hand (otherwise you waste time optimising code that is not important).

But these are some tricks to keep in mind when using C++.


The for loop:

A generic for loop:

Seems pretty imposable to optimise. But you look at the standard way of implementing the ++ operator on C++ classes.

Because the postfix increment should happen after the expression has been completed, you need to create a copy of the 'this' object in its current state and return that for use within the expression. You can then increment the 'this' value now so it is correctly defined for later use. I know this feature is not used in the above loop, but the post increment will normally be implemented to behave just like it does with builtin types. See example below.

What is also hidden is that this actually takes 2 extra calls to the copy constructor. The first call creates the copy. The second is a call to copy the value out of the operator into a temporary for use by the expression (this is because you can not return by reference).

So how do you get around this problem? Well the solution is as simple as the problem. You use a prefix increment operator.

Here the implementation is very nice and clean. No calls to the copy constructor required.

A nice read with topics like this and others:
http://www.tantalon.com/pete/cppopt/main.htm


p.s. : Is there any free profiler for C++ on windows that anyone know of ? (Without me needing to use mingw or cygwin coz I don't have enough space for it atm)

i think the using namespace cmd saves space because ur not writing all the std::cout<<std::endls

Is it really that difficult to type std:: ? Or at least use using declareation in local scope. Dumping everything to global is just BAD.....

ehh.. well everybody here awhile back when there were about 100-200 people told me to use namespace rather than typing std::, however i can go any way

is just convenient to recommand to beginners so that they can learn C++ without having to know the exact details of namespace. However, when one start to progress on one's knowledge of C++ and write anything that's beyond a toy program, the using directive dumping everything into globals is just evil...

um, using namespace std; instead of std:: certainly does NOT reduce the size of a compiled program.

And using pre-increment instead of post-increment wherever possible is always a good idea.

brett

another thing that can make stuff a little smaller in win32 when windows.h is included is typing #define WIN32_LEAN_AND_MEAN and that will strip down the header a bit but you may get undefined errors so you have to include the specific headers then. so i guess that means dont include every header file you have just the ones you need ^_^

Some compilers automatically optimize your code. Example: Borland Command-Line Compiler

yes they do, however if its optimizing good code it will still be a lot better than it trying to optimize mediocre code.

Another thing that you can do is search for a better algrothim to use. EG: using quick sort rather than bubble sort. (Compilers can't optimize bad math choices)

When using nested loops always ask yourself if the nested loop can't use information from the top loop so that it doesn't need so many loops. Example:

Can be optimized to:

The effect is exactly the same but the sencond needs only half as many loops as the first.

Consider inline ASM always as the last option. Once you use it your code is not as easy to read anymore and algrothim amelorations are much harder to implement.

Hi Dr V.

You need to indent your second for statment to make it easier to read :P

Your first code has a complexity of O(N^2)
While your second has a complexity of O(N.log(N))

A definite improvement in complexity terms. But do you really gain anything.
You are makeing the algorithm more complicated to understand but doing exactly the same amount of work. (ie you are still calling the function 'col()' on every single element in both arrays.

I wouldnt consider inline asm as a last option it may break the standards but if youy get used to using it then at least you will know that you can do and how to do it alos you will have a much better understanding of how your computer works and will have an easier time optmizing (once you inderstand how C++ does what it does). and i usualy place (basic usualy not working or not working correctly or not fast enough) C++ code comments with my inineasm code in my C++. saves a lot of time when debugging :)

huge tip for optimization:

compiler arguments:
-Os (for small binaries)
-O3 for largeer binaries with faster lstartup
-O2 all around balanced imo
-fomit-frame-pointer
-funroll-loops
-pipe
-march=athlon-xp
-mcpu=athlon-xp


the latter can be done manually in the code too, but will make it les readable and unrolling loops always increases file size (and speed too :) )

Prelink: prelink your binaries for increased speed

try to use more const references when passing objects instead of passing them each time by value

will require less copies in the stack (a lot less) thus reducing the amount of times a constructor/destructor is passed through.
can be usefull for large applications with many objects

oh, one very nice hint:

use linux. Linux binaries aere a lor smaller than windows binaries.
(KDevelop, a IDE like VC++6, its executale is only 256K on my build)
a small app, in Qt written, linux: 100K (pics in xpm included) windows: 1.05MB (also pics in xpm included)

I only indent when I use {}s.

You only need to compare b half as often against size then without it. Also you safe lots of jumps.

Often when you come to such a situtation you often put a condition before col. And often if this condition is true for a with b then it's also true b with a. So you safe half of the comparisons. For example:

In some situation the gain will be little but nearly always it is worth the little effort needed for the optimization.