Open woodpenker opened 2 years ago
What is the goal? How did you discover that this may be an issue? Could you describe why do you think this is the part of the algorithm that is troublesome? Could you share your performance testing methodology? Could you share an example of the data? Etc.
My point is that depending on a use case various part of the algorithm are going to be slower or faster. I'm curious why do you think that reallocations are the cause of your problems if there are any.
Reallocations are of course bad in general so we could think about avoiding them. They are in push_back
s:
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/detail/sections/sectionalize.hpp#L492
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/detail/sections/sectionalize.hpp#L545
which use _M_realloc_insert
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_vector.h#L1287
If you're willing to do some testing:
Sectionalize is called here: https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/detail/overlay/get_turns.hpp#L531-L539 Sections used there are defined here: https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/detail/sections/sectionalize.hpp#L134
You can try deriving them from std::deque
instead of std::vector
.
Or you can try calling reserve()
, e.g.:
sec1.reserve(geometry::num_points(geometry1) / 2);
sec2.reserve(geometry::num_points(geometry2) / 2);
// or use some other estimate
We found that using
boost::geometry::intersection
will lead to a lot of_M_realloc_insert
forstd::vector
. The callstacks may like this:After reading the codes, I guess it may caused by
Section
at this line: https://github.com/boostorg/geometry/blob/c011ebfb4f095fabb0f770c9c09c59a6eacba0a7/include/boost/geometry/algorithms/detail/overlay/get_turns.hpp#L533. Is it right and does we need to consider the reallocation performance cost?