Re: [fusion] Proposal for deprecating fusion.tuple.

On Sat, 30 Sep 2017 07:07:11 -0500
Larry Evans <[email protected]> wrote:
> On 09/29/2017 08:23 PM, Kohei Takahashi wrote:
> > Hi Lee,
> >   
> >> How does `fusion::tuple` make `fusion::vector` implementation more
> >> complex? Are you referring to the C++03 or C++11 version?  
> > C++11 is.  
> [snip]
> >> I would like to point out that recent tweaks to
> >> `fusion::vector` have [improved performance over libstdc++
> >> `std::tuple` in construction][0][1].  
> > Interesting. I'll try to benchmark simpler impl.  
> Kohei, the benchmark [0] mentioned by Lee for fusion::vector is here:
> 
> https://github.com/ldionne/metabench/blob/master/benchmark/hetero/make/fusion.vector.cpp.erb
> 
> AFAICT, it only makes the vector, it doesn't access any elements.
> I would think having to access the elements would affect the
> compile time since that would require instantiating member functions
> and I'd assume that would take some more compile time.  Is that
> assumption wrong?  If not, then maybe a better benchmark would
> exercise some of the more important member functions.

There is a [benchmark for the `at` functions][0][1] which are not
great. It creates a vector using `make_vector` then accesses each
element via `at_c<...>`. The growth rate is roughly linear (as compared
to `fusion::list` which must "iterate"), but still climbs fast.
AFAIK, it is faster than the C++03 version, which should look similar
to `fusion::list` in that graph. The complication is probably in the
[base implementation][2], which cannot be removed easily. However,
`boost::fusion::get<...>(...)` can be made much faster by _not_ using
`at_c`, and instead interact with the `detail` types directly. This is
one of the reasons I wanted to keep `fusion::tuple` around - if we
documented that `fusion::tuple` and `fusion::get` were faster in some
cases then users could use that when they didn't need some of the
conversion behavior of `fusion::vector`. Their code would work going
back to C++03 mode, and automatically see lots of compile time
improvements when switching to C++11 mode. The biggest "transparent
gains should be internally in Spirit, but that uses `fusion::vector`
everywhere.


Also, the top-level domain `metaben.ch` has loads more benchmarks that
might be of use.

> >   
> >> Anyway, the bigger issue with deprecation will be on users of
> >> Boost. Hopefully the fix would be easy - just change to another
> >> sequence type. I'm not aware of an situations where this is _not
> >> true_ (i.e. where deprecation would cause major code re-write for
> >> Boost users).  
> > Yes, I think so too. I'll post this proposal to devel/users ML and
> > ask who uses `fusion::tuple` in production code.  
> If by devel ML you mean:
> 
>    [email protected]
> 
> then be prepared to wait for a reply.  The last post I made to that ML
> was sent 9/24 at around 6pm Chicago time.  It's now 9/30 and it hasn't
> shown up yet :(
> [snip]
> > Thanks,
> > Kohei
> >   

Lee

[0] http://metaben.ch/hetero/clang++-4.0/at/index.html
[1] http://metaben.ch/hetero/g++-7/at/index.html
[2]https://github.com/boostorg/fusion/blob/develop/include/boost/fusion/sequence/intrinsic/at.hpp#L66

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot