Repository navigation
Possible optimization in v2 branch #36
Description
The geometry decoding in https://github.com/mapbox/vector-tile/blob/2.x/include/mapbox/vector_tile/handlers.hpp works by first creating "multi" geometries of the given type. If later the geometry turns out to only contain a single point, linestring, or polygon, the first geometry of the "multi" is returned. In practice most geometries are probably not multi, so creating this extra indirection (which internally is a std::vector) and then discarding it could have measurble performance impact.
Activity
flippmoke commentedon Jan 29, 2018
@joto I am not quite sure how I want to approach this problem, but I knew it quite well when I wrote this that it would occur. All of the other options seem to have downsides if I remember as well which is why I settled on this design.
joto commentedon Jan 29, 2018
This is probably something where we need to benchmark different implementations and see where that takes us. I suggest we first benchmark the current implementation and then one that can only handle non-multi geometries which should be easy to implement. This should give us an upper bound on the performance improvement this could have in the best case. If the numbers tell us that this is worthwhile to persue, we can try different implementations.
flippmoke commentedon Jan 29, 2018
@joto These should be fairly easy tests to make in our existing benchmark system. I will look into getting this done at some point (not planning on this anytime soon), or you could do it as well.