Re: [boost] [fusion][parameter] a solution for named parameters/parameter packs using fusion maps

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-14 01:24:49

On Wed, Aug 13, 2008 at 1:51 PM, David Abrahams <dave_at_[hidden]> wrote:

>> but after deciding not to use the library because of the first reason
>> I listed, I didn't really feel motivated to look into it further.
>>
>> Finally, I was concerned about the impact on compile time, which I've
>> seen mentioned on the list a few times.  Whether what I have now is
>> any faster is yet to be tested.
>
> I'd be interested in hearing the results.
>

OK I felt motivated to get some results :-)

I tested on the following use case:

class named_constructableN
{
public:
    // a macro could extend the number of parameters if desired
    template<typename FM0, typename FM1, typename FM2>
    named_constructableN(const FM0 &a0, const FM1 &a1, const FM2 &a2)
    {
        label = (a0, a1, a2)[labelN];
        size = (a0, a1, a2)[sizeN];
        volume = (a0, a1, a2)[volumeN];
    }
    std::string label;
    int size;
    double volume;
};

//...
    named_constructableN constructed(labelN = "hello", sizeN = 1,
volumeN = 1.0);
    BOOST_CHECK_EQUAL(constructed.label, "hello");
    BOOST_CHECK_EQUAL(constructed.size, 1);
    BOOST_CHECK_EQUAL(constructed.volume, 1.0);

I put together three versions of the test - one using the fusion based
solution (I'm calling it field_map), one using the same use code but
using Boost.Parameter, and then one using the recommended
Boost.Parameter method for constructors.

I then varied the number of "replicas" of the above code for the test.
 The following times were reported for 2 replicas in each test case:

user: [test_field_map_compilation.o] 0.000249
system: [test_field_map_compilation.o] 0.000028
user: [test_parameter_compilation.o] 0.000102
system: [test_parameter_compilation.o] 0.000013
user: [test_parameter_dispatch_compilation.o] 0.000135
system: [test_parameter_dispatch_compilation.o] 0.000015

And the following for 20 replicas:

user: [test_field_map_compilation.o] 0.002128
system: [test_field_map_compilation.o] 0.000139
user: [test_parameter_compilation.o] 0.000195
system: [test_parameter_compilation.o] 0.000030
user: [test_parameter_dispatch_compilation.o] 0.000555
system: [test_parameter_dispatch_compilation.o] 0.000041

I committed the tests to the sandbox, if you're interested in the
details (I'm not sure whether I designed the tests adequately):
http://svn.boost.org/svn/boost/sandbox/guigl/libs/guigl/test/

So, to revisit my speculations, these results would indicate that the
fusion-based approach (as I have it implemented, at least) is
significantly slower (in terms of compile-time) than using
Boost.Parameter with the same syntax.  Since it turned out that
Boost.Parameter supports that same syntax, the fusion-based approach
also isn't less convoluted, as I suggested it might be.  Of course,
perhaps I am again being hasty  :-)

Kind regards,

Stjepan