Re: [boost] [fusion] segmented fusion 2.0

Subject: Re: [boost] [fusion] segmented fusion 2.0
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-19 17:41:08

>>> On 8/12/2011 9:46 AM, Eric Niebler wrote:
>>>> 4) Wait for the dust to settle. Assuming all is looking good, try making
>>>> joint_view segmented.

I tried this today. It flushed out a couple of bugs in my segmented
fusion code, but other than that, it Just Worked. That is, if joint_view
merely exposes its internal segments (no need for joint_view_iterator),
then all tests pass. This is a significant accomplishment. It meas that
certain kinds of fusion data structures can be implemented very easily
with no loss of functionality.

I won't be committing that change, though. Compile-time performance for
iterating through a joint_view is terrible. It seems single-stepping and
comparing generic segmented_iterators is *much* more expensive than the
same operations with the more specialized joint_view_iterators. For
instance, the functional/invoke.cpp test takes 4-5x longer to compile
(gcc 4.3, msvc 10) with generic segmented iterators! This is
disappointing. I'll need to use the template profiler to see what's
going on. Maybe I've just overlooked something obvious.

Of course, single-stepping through a joint_view isn't necessarily the
most common use scenario. These things will also be passed to fusion
algorithms, which (if they are segment-aware) may in fact compile
/faster/ if joint_view is segmented (unconfirmed). :-/

Regardless, it seems I need to improve the compile time of incrementing
and comparing generic segmented iterators.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com