Possible optimization in v2 branch

[joto]

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.

[flippmoke]

@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]

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]

@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.