Subject: Re: [geometry] [index] rtree iterative queries
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-09-15 20:25:46
Hi Bruno,
Bruno Lalande wrote:
> Hi Adam,
>
> Sorry for the late answer... Thanks for that, I'm fine with this
> solution. If you still have problems or concerns about performance of
> type erasure maybe you could dig into how Boost.Function implements
> that without virtual function calls? Efficiency figures are presented
> here:
> http://www.boost.org/doc/libs/1_54_0/doc/html/function/misc.html#idp60516496.
> You could even have the predicates implemented in terms of
> Boost.Function which would de-facto make them type-erased instead of
> the whole iterator... Just a general thought though, if you happy with
> your implementation just keep it like this.
>
Thanks for the suggestions, I haven't thought about Boost.Function. I've
just tested this approach. Maybe there is some more optimal way of doing
it (I'm binding each method instead of making it virtual) but those
iterators are slightly slower. I think it's because somehow the function
must be called, somehow the dispatch between the types must be done and
the way the compiler does it is probably the most optimal. Moreover
including Boost.Function would be additional dependency so for now I'll
leave it as it is. If you like to check it out for yourself, various
implementations may be enabled in
geometry/index/detail/rtree/query_iterators.hpp file.
As for the type-erased Predicates I thought about it too. Unfortunately
not only Predicates would have to be type-erased. The internals of the
iterator are different for spatial and knn queries so they should also
be type-erased, and those internals are the major part of the iterator.
But the support for type-erased predicates could be useful for the same
reason why the type-erased iterator is. E.g. someone could store
Predicates and later pass them to the query() function. Though I'm not
sure if this functionality is needed and makes sense because the
predicates are still defined in compile time. What could really be
useful are run-time predicates which could be connected together in
run-time and then passed to the query but this is probably more distant
future.
Regards,
Adam