> std::variant. The high compile times stem simply from the fact we have
> to cycle through the Cartesian product of the set of types of each
I absolutely agree on that diagnosis, but I think std::variant can play a
role. The key
is to postpone dispatch, where possible, to refactor out one or more of the
product
terms.
At the moment the dispatch mechanism identifies all the concrete types
first, *then*
runs the correct instantiated function. If there were more flexibility in
this process,
dispatching to selected type-dependent code could happen later and cover
less code.
Consider:
template<class A, class B, class C>
void foo(A a, B b, C c)
{
// lots of A and B code
// a single use of C
// lots more A and B
}
For the sake of a small amount of code involving C the entire function gets
rebuilt as
many times as there are C types. Now consider an approach that postponed
determining C's concrete type:
template<class A, class B>
void foo(A a, B b, std::variant<C1, C2, ...> c_var)
{
// lots of A and B
std::visit([](auto const & c){ // use of C }, c_var);
// lots more A and B
}
If C was something based on scalar_types this would mean a factor of 6
reduction in
instantiations!
It's true that you could do the same trick - though IMO less cleanly - with
boost::any and
a typelist. But this would leave off the other advantage of variant:
constant time dispatch.
I don't know what the runtime impact of the current iterative approach is,
but it seems like
it could particularly important in filtered graphs, or in algorithms with a
lot of callbacks
(like my personal favorite, astar_search).
On Thu, Feb 6, 2020 at 5:09 AM Tiago de Paula Peixoto <[email protected]>
wrote:
> Am 06.02.20 um 07:12 schrieb Jeff Trull:
> > Would there be any interest in exploring this kind of refactoring? I
> > think there could be substantial benefits in compile time, as well as
> > some runtime improvement (depending on how often the Python/C++ boundary
> > is crossed).
>
> I don't think the important issue is whether we use boost::any or
> std::variant. The high compile times stem simply from the fact we have
> to cycle through the Cartesian product of the set of types of each
> parameter. I don't see how using std::variant changes this in any way.
>
>
> --
> Tiago de Paula Peixoto <[email protected]>
> _______________________________________________
> graph-tool mailing list
> [email protected]
> https://lists.skewed.de/mailman/listinfo/graph-tool
>
_______________________________________________
graph-tool mailing list
[email protected]
https://lists.skewed.de/mailman/listinfo/graph-tool
