Erik wrote:
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
Andrew Holden skrev: 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.