Replies: 5 comments 7 replies
-
Well, you have to create all the "leaf" objects first before you can start making the vector, so someone has to store the values. It's either the app (i.e., you) or we store them internally. Flatbuffers only rarely (like 3 cases that I can recall) creates any heap memory, so we don't want to store a dynamic sized array. So we prefer to pass the offsets back to the app and they can determine the best way to store it. There are some tricks we can play when when serializing vectors of strings where we use the 'scratch buffer' of the backing buffer to store the offsets, but this might cause a buffer resize and be just as expensive. I wouldn't worry about the speed/size of this vector, it should be tiny and scale with the size of |
Beta Was this translation helpful? Give feedback.
-
Thanks for your attention and answer. How about this CreateUnitializedVector() function? Let's say, I already know size of the table during serialization call, so first I can create UnitializedVector() with known size (but offsets not set yet), then serialize every table item, and after every item when I get the offset I put this offset into previously allocated vector, settings offsets one by one. This way, vector comes before table items, is that a problem? As we are operating on offsets, isn't it possible? That would solve this whole issue. |
Beta Was this translation helpful? Give feedback.
-
I started to use flatbuffers on PC side, and I like it a lot. I'm embedded guy at heart and it's almost perfect, very far from allocation fest (like some other serialization protocols), less that vector issue. But it's acceptable there. |
Beta Was this translation helpful? Give feedback.
-
I'm also trying to avoid double-copy when building a flatbuffers vector. In my case it is a simple
So if I could access the flatbuffers-allocated payload vector and write to that directly. This way I could do a single Any API calls to achieve this? Maybe accessing Update: looks like |
Beta Was this translation helpful? Give feedback.
-
I'm using CreateUninitializedVector to allocate space for vector, and fill it later. But for raw byte stream, nothing sophisticated, particulariy not to optimize out temporary vector (main case in this thread). With such simple usage, it certainly works without any data corruption, as far as my case goes. Tested, no problems. But I'm not using CreateRow(). |
Beta Was this translation helpful? Give feedback.
-
Hi, thanks for the great library! I'm successfully using it for my needs, due to low memory usage overhead design. But still, I'd like to optimize a little bit more. I have the following usage example:
And C++ code:
And that's mostly fine, but is it really required to use fb_items temporary vector? It's wasteful, unnecessary memory allocation and loss of time. I experimented with CreateUnitializedVector(), but the documentation is lacking, and I've come to the conclusion that it's designed for POD scalar types, not tables.
Hot to get rid of this temporary vector, could you advise?
Beta Was this translation helpful? Give feedback.
All reactions