Currently a vector_tile::Tile needs to be passed to mapnik::vector_tile_impl::backend_pbf and then the calling application is expected to call tile.SerializeToString() to get the encoded string for the entire tiles layers.
When encoding tiles with lots of layers this means that the vector_tile::Tile is going to grow in size during rendering to hold all the layers and this can use a significant amount of memory.
I have a hunch that a faster (or at least lower memory approach) would be to serialize per layer. So the API could change so that:
Instead of passing a vector_tile::Tile into the backend a std::string could be passed.
Internally the mapnik::vector_tile_impl::backend_pbf could do serialization per layer and therefore internally manage memory more wisely
Another advantage of this is that it removes the need for the google protobuf structures in the public API and this would help further reduce the google dependency in our quest to completely remove it in favor of https://github.com/mapbox/protozero (refs #152)
Currently a
vector_tile::Tile
needs to be passed tomapnik::vector_tile_impl::backend_pbf
and then the calling application is expected to calltile.SerializeToString()
to get the encoded string for the entire tiles layers.When encoding tiles with lots of layers this means that the
vector_tile::Tile
is going to grow in size during rendering to hold all the layers and this can use a significant amount of memory.I have a hunch that a faster (or at least lower memory approach) would be to serialize per layer. So the API could change so that:
vector_tile::Tile
into the backend astd::string
could be passed.mapnik::vector_tile_impl::backend_pbf
could do serialization per layer and therefore internally manage memory more wiselyAnother advantage of this is that it removes the need for the google protobuf structures in the public API and this would help further reduce the google dependency in our quest to completely remove it in favor of https://github.com/mapbox/protozero (refs #152)