Is it possible to optimize memory usage in C++ protobuf arena?

[chenbd]

Dear developers,

Is it possible to use pooled memory like protobuf arena when deserialize a buffer to message?
eg, for nds.live, when construct RoadLayer form SmartLaterTile's data layer blob.

[mikir]

Yes, we support standard C++ allocators. You can pass allocator to the contructor of generated objects.

It is possible to influence used C++ allocator by Zserio command line argument -setCppAllocator. This argument sets the C++ allocator type to be used in generated code. Possible values: std (default), polymorphic. Explanation:

• std stands for std::allocator<> class implemented in standard C++ library
• polymorphic stands for zserio::pmr::PropagatingPolymorphicAllocator<> class implemented in Zserio C++ runtime library

[Mi-La]

With polymorphic allocator you can use your own zserio::pmr::MemoryResource.

[chenbd]

Thanks for your answers.

I tried -setCppAllocator polymorphic, but seems my code need changes because a lot of types changes.
something like zserio::vector to zserio::pmr::vector.
I open this issue because considering whether i can have a per tile allocator, when user want the tile, create the allocator, read tile data to smart layer tile, all layers memory from the allocator. and deallocate when tile destroy.

[Mi-La]

Yes, unfortunately the allocator approach changes the types. On some places you can use auto to prevent need of changing the code when changing -setCppAllocator option.

[chenbd]

After some code fixes, the polymorphic works now. and i added a memory resource per tile, allocating 4KB memory when doing allocate.
I did not see big performance difference with default std.

And i found that the memory used when deserialize the smart layer tile is a little big, eg:
the serialized smart layer tile is 300KB with a few(10) layers, after deserilize all layers, the memory resource total allocate 6MB memory, about 20 times bigger.
my question:

• Is there any suggestion when should use polymorphic?
• whether the memory used (in my test case) when deserialize is too big?

[Mi-La]

In general, you should use polymorphic allocator when you need to manage the memory by yourself. Thus you can implement various allocation strategies and choose what fits best for you. E.g. you can use single memory pool for whole application (e.g. monotonic_buffer_resource), or several memory blocks, one per each module, etc.

Regarding the size of deserialized data, it all depends one the concrete schema. For example, when the schema contains many small nested arrays, the std::vector is used in generated C++ code for each array. And std::vector itself has 24B overhead in memory. Moreover the schema can contain packed arrays, which reduces the size of BLOBs yet further. In general, the size ratio is quite normal because zserio binary format is quite well optimized for size.

Unfortunately we are not able to help you with issues related NDS schema, since zserio (this repo) is only a generic serialization framework. Please contact NDS support if you are NDS member or please check NDS web site otherwise.

[Roland-Homeier]

How is the allocation especially in nested structures of a std::vector in Zserio? Is a std::vector allocated with a size larger than 0? This might not be such a good idea for some cases like where i is deeper nested and some of the vector are empty or containing only a less number of elements compared to the default element size of a container.

[Mi-La]

In general, we don't preallocate anything (except of the reader part where we exactly know the size of an array). However even the empty std::vector requires 24B (8B size, 8B capacity, 8B pointer) - and it's yet more with a custom allocator when the allocator iself has some footprint - e.g. + 8B for polymorphic allocator since it has to hold pointer to the memory resource.
When the array part of an another array, then it's on heap and thus it requires the 24B + the real data size. And yes, it's not ideal for lot of small arrays of small elements. Whether the "big" overhead of vector arise in runtime is fully dependent on a concrete schema. But if it causes serious problems, we will have to think up a better solution.