David Abrahams writes:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message
"Arkadiy Vertleyb" <vertleyb@hotmail.com> 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