On Mon, Mar 28, 2011 at 12:21 PM, Thomas Heller <thom.heller@googlemail.com> wrote:
Are you serious? Please write real benchmarks. By executing the resulting
Hello all, I have profiled Boost.Local against all the alternative methods I know for local functions: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local... I was able to optimize Boost.Local code so it always runs as fast as Local Functors. However, both Boost.Local and Local Functors run significantly slower than Global Functors, Boost.Lambda, and Boost.Phoenix on non C++03 compilers (see "Boost.Local Compliant"). On C++03 compilers, Boost.Local runs faster than Local Functors and as fast as Global Functors, Boost.Lambda, and Boost.Phoenix. All of that when compiler optimization is used; When no compiler optimization is used Boost.Local runs faster than both Boost.Lambda and Boost.Phoenix. Boost.Local always compiles relatively fast and the same is true for Boost.Lambda but not for Boost.Phoenix. I have also listed binary sizes. For the run-time, the point seems to be that the Boost.Local trick that allows to pass local classes as template parameters requires 1 indirect function call via a function pointer: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local... This indirect function pointer call can only be resolved at run-time so compiler optimizations that inline all Boost.Lambda and Boost.Phoenix functor calls cannot inline Boost.Local functor calls. On C++03 compilers, Boost.Local passes the local class functor directly as template parameter avoiding the function pointer indirect call and therefore allowing for inlining all the Boost.Local functor calls when compiler optimization is enabled. I would think that the run-time cost of Boost.Local on non C++03 compilers (i.e., the use of 1 function pointer in resolving the local function call) might still be acceptable in applications that already use a number of indirect function calls (via function pointers, virtual functions, etc). Furthermore, I have not experimented how the run-time performances of Boost.Local and the other approaches are affected by programming more complex instructions in the local function body (the local function used in this analysis simply adds the elements of an array and it contains only one instruction `sum += factor * num`). What do you think? Thanks. -- Lorenzo