Design complexity prevents compiler optimizations

[Andrey Semashev]

While debugging my application I discovered that the compiler (gcc 4.6 with -O3) fails to optimize even the simplest Boost.Phoenix v3 expressions. For example, the following function object:

phoenix::bind(&media_session::set_local_description, &session(), boost::cref(sdp))

when invoked, generates 7 (seven) nested operator()/eval calls before actually reaching the media_session::set_local_description method. This doesn't take into account any other possible overhead that I'm not seeing in the stack backtrace. Changing phoenix::bind to boost::bind reduces this backtrace to only 3 operator() calls before media_session::set_local_description is reached.

Please, simplify the library to improve its efficiency. As a side note, the complicated design of the library also increases compile times and possibly resulting binary sizes (I haven't done any research on the latter, but I was suggested that in ticket #8820).

[Andrey Semashev]

Some explanation: &session() returns media_session*, and sdp is an object of a user-defined class. So there isn't any added complexity besides phoenix::bind.

[Thomas Heller]

The number of observable backtraces in gdb do not give any indication about the efficiency of the library. Sure, boost.bind gets away with less. Phoenix just does more. Most of those function calls you see come out of proto.

FWIW, tests have been conducted by the author of Boost.Local which investigated exactly those issues raised, all of them raised in this ticket could not be verified (http://www.boost.org/doc/libs/1_54_0/libs/local_function/doc/html/boost_localfunction/alternatives.html).