[boost] Re: mpl::begin<mpl::vector<...> > performance problem

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-03-01 05:46:14

David Abrahams writes:
> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
>
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>
>>> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
>>>
>>> > Hi all,
>>> >
>>> > I am having a huge compile performance problem trying to use mpl::begin
>> for
>>> > an mpl::vector of a large size -- the complexity seems to be far from
>>> > constant (or even linear) time.  The following example demonstrates it
>> (I am
>>> > using GCC 3.3.3 or 3.4.2)
>>>
>>> Are you sure you're not seeing preprocessor slowness?
>>
>> I modified the example to get the PP code out:
>>
>> typedef BOOST_PP_CAT(boost::mpl::vector, BOOST_TYPEOF_LIMIT_SIZE)<
>> BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, MACRO, ~)
>>> v;
>>
>> #warning started getting begin
>> typedef boost::mpl::begin<v>::type it;
>> #warning done getting begin
>>
>> It takes about 35 seconds between two warnings....
>>
>> The similar problem seems to exist for at<>.  It takes forever to compile
>> at<v, int_<0> > in the same context.
>
> Well, we need to hear from Aleksey on this one, I guess.

I haven't had a chance to look at it in detail yet, but I'm pretty
sure that the penatly comes from simply _instantiating_ the vector
type with a huge number of elements. 'begin' just happened to be the
first metafunction that causes that in Arkadiy's code. Of course that
doesn't mean that it's not an issue, especially since we guarantee
that "predefined" content specification has amortized constant
time complexity. At the very least, if we find out that there is
nothing we can do, the docs would need to be fixed.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering