Repository navigation
Which has better performance in serializing custom data structures, CAF Inspect or Protobuf? #1782
|
I am using CAF to build radar application software, but now I have encountered a problem: the custom structure nests multiple vectors for storing binary data and interacts with actors on other hosts via a 10G Ethernet, that is, implementing custom message interaction between remote actors through the network. However, during debugging, I found that the function |
Replies: 1 comment 5 replies
|
Did you dig deeper into what is eating up the time in that
Just to be sure, we're talking about the However, I don't think Protobuf would solve the performance issues that you see. Of course it's always better to verify this with a micro benchmark. If you find Protobuf serializing and deserializing the same data structure faster than CAF, please let us know. FlatBuffers might help. Not because of the network representation, but by improving cache locality and reducing heap allocations. But you could probably achieve the same with a custom allocator or maybe even by redesigning your data structure to avoid nested, heap-allocated containers in the first place. Hope that helps. 🙂 |
|
Thank you very much, what you said has been very helpful to me. Through benchmark testing, I can confirm that the long execution time of the inspect template function I implemented is due to too many nested Vec, which has created a performance bottleneck. You mentioned earlier that in my scenario, the nested Vec significantly impacts the performance of the inspect function because it leads to multiple heap memory allocations and results in a low cache hit rate. What do you mean by "using a monotonic buffer resource"? Additionally, I would like to ask, if I use jemalloc or tcmalloc as the heap memory allocator, could it speed up the inspect? |
|
I'm referring to the monotonic_buffer_resource from the standard library (have a look at what's in As for other heap allocators like |
|
Fantastic answer, I think I've found the answer. The reason for the low serialization performance of my data structure is firstly due to the deep nesting of the data structure, especially for vectors, where there is multiple nesting, because I simply used vector to implement a two-dimensional array. Secondly, it's because the data size is too large, at least reaching 4MB. Based on these two points, I think I can optimize this data structure soon. |
|
Sorry, it seems there was a problem with my previous debugging approach, and I think I've found the reason affecting the serialization performance. My custom struct indeed nested several layers of Vec, but what ultimately affected the performance was the underlying Vec, here is the definition of IqItem: |
|
I don't think I can really follow your train of thought here. If you could provide a reproducer, I could take a look tho. |
I'm referring to the monotonic_buffer_resource from the standard library (have a look at what's in
std::pmr). If you have containers that only grow (ideally immutable after construction), they are a good choice. Although you might want to switch fromvectortolistin that case to avoid "holes" in the buffer (from growing avector) unless you can alwaysreservethe proper size right away.As for other heap allocators like
tcmalloc: it really depends on the allocation patterns in your application. Maybe plugging in an alternativemallocimplementation will speed up your application enough. But the only thing I can recommend here is trying it out and measuring it.