Re: [Boost-users] Container iteration macro that is equivalent to handcoded iteration?

From: Andrew Holden (aholden_at_[hidden])
Date: 2007-10-11 12:49:05

Erik wrote:
> Andrew Holden skrev:
>> Erik wrote:
>> 
>>> Unfortunately it does not look so good for BOOST_FOREACH after this
>>> modification. It will increase to 24 instructions, while the
>>> handcoded is still only 21. I created a script
>>> (attached) to test the examples systematically with different
>>> compiler versions and optimization levels.
>>> 
>> Forgive me if this was answered in an earlier post,
> The answer is available by executing the test script in my
> previous post and then running the diff command that I showed in that
> post: diff -dU2 iterate_vector-member-g++-4.2.0-O3.s
> BOOST_FOREACH-member-g++-4.2.0-O3.s|kompare -
> 
>> but how complex is the loop body, including the complexity
> of any functions it calls?
> The size of the loop body increases from 6 to 7 instructions
> and the code before the loop increases with 2 instructions.

Okay.  I see that the loop body contains a call to a function "f", which
is not defined.  Here is the code from one of the tests:

//Begin BOOST_FOREACH-parameter.cc
void f(float);
#include <boost/foreach.hpp>
#include <vector>

void g(const std::vector<float> & v) {

   BOOST_FOREACH(float i, v)
      f(i);
}
//End BOOST_FOREACH-parameter.cc

We would need to know the contents of f before we can really discuss the
consequences of the extra instructions in BOOST_FOREACH.  Even if f is a
stub, it will still have compiler-generated prolog and epilog code,
which will diminish the importance of the extra instructions you found.
If f is sufficiently complex, then using BOOST_FOREACH instead of a
handcrafted loop may add less than a second to a multi-hour run.

It would also be useful to know the size of the vector.  As the vector
grows, the extra instructions outside the loop rapidly diminish in
importance.

I would strongly recommend getting a copy of Valgrind (or another
suitable profiler for your platform) and doing some profiling runs with
various combinations of "f" implementations and vector sizes.  If
nothing else, you can use the "time" program to measure how long your
test programs run.  I suspect you will find that the performance penalty
for BOOST_FOREACH to be minimal, perhaps even swamped by experimental
error in some tests.  After that, determine for yourself if the improved
expressiveness from BOOST_FOREACH is worth the (probably small) price in
performance.