Some questions regarding performance.

[karan bhatia]

Hi, 

I am pretty new to FlatBuffers and was evaluating its potential use. I currently only have a very vague idea regarding its internals. Some questions:

1) From the tutorial - "For this reason FlatBuffers can also be mutated in-place. While this is great for making small fixes to an existing buffer, you generally want to create buffers from scratch whenever possible, since it is much more efficient and the API is much more general purpose."

What's the performance for mutation like? Is it still better than protobufs which allow for easy mutation? There's also the difficulty mentioned with mutating default values.

2) For adding elements to vectors- It seems that reflection can be used to mutate the size of vectors etc or copying data from an existing flatbuffer. But it seems the support for it is experimental. Can you confirm this?

3) I see that flatbuffers has an object based API which allows for easy mutation, construction etc.

  - This is not experimental right?

  - Do you have benchmarks regarding what's the performance like with this? Is performance of deserializing a flatbuffer to a C++ object, still comparable to deserializing a protobuf?

  - If we pass --gen-object-api, there are some more fields generated. What's the memory cost like for representing a FlatBuffer with this flag? I would expect the performance of constructing a FlatBuffer to not change much. Is this correct?

[mikkelfj]

I am not very familiar with the C++ mutation interface so I will let Wouter answer those details.

The general performance advantage of flatbuffers is that memory can be read directly without allocating memory like you would when reading msgpack, json, protobuf etc.

As soon as you start to do any complex changes you essentially have to write a new buffer. Various experimental or less experimental api's may buffer changes before writing them out, which can be fast compared to alterternatives, or not, but it is not where you find the primary benefits of flatbuffers.

For very simple changes you can modify the memory of a flatbuffer in-place. For example and integer can change value from 42 to 27. A vector of integers can change each element in the same way, but it cannot change its length without either wasting space (truncation), or rewriting the entire buffers (extension).  In C++ this can be very fast. In C it is not supported, in part because it is unsafe and is of limited use. For other languages I doubt this is supported, but I don't know.

Default values are not stored in the buffer, it is a value the generated code returns when a value is absent, so changing the value is not possible without rewriting the buffer.

Direct changes in flatbuffers is not safe if you do not 100% trust the flatbuffer - even if you verify the buffer it is not thorough enough to be safe when the buffer is modified, so I will not recommend it in most cases. The problem is that two different sub-structures of the buffer can be valid while placed on top if each other. Flatbuffer builders never do this, but it is possible. and a verifier will usually accept this. If you then start changing the buffer, this can trigger buffer overruns, for example if a vector length and a hit counter uses the same memory in the buffer and you change the hit counter.

Direct, or indirect changes of flatbuffers limits portability because the supported logic for doing so likely varies signficantly between languages, and even if supported, it might be relatively expensive to do in some languages while nearly instant in C++.

I believe there can be done much more in flatbuffer API world in different languages for buffering changes but the C++ API already does some work here - facebook did some work on their own that hasn't been released.

https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/

In conclusion, write flatbuffers, read flatbuffers, write new flatbuffers. If you are lucky, the API allows you to easily copy data from the old buffer into a new buffer, but this support varies by language and is most mature in C++ with help of reflection (which is not optimally fast because it does not use code generation for copying complex structures).

If you need extensive modificatins, a really fast json parser is an interesting alternative - it is slower because of memory allocations, but these allocations also make it simpler to mutate, and json can be read as flatbuffers if you use a compatible subset of json. In C flatbuffers based json parsers and printers are only 4 times slower than building a native flatbuffer. - but these do not support mutations.

[Wouter van Oortmerssen]

We have 3 ways of mutating:

- In-place, for scalars. Very fast, but limited.

- In-place using reflection. Slightly less limited but slow.

- By (un)packing to and from an object-tree representation, much like ProtoBuf. Decently fast, biggest cost is allocating/deallocating. Allows absolutely any kind of mutation with a nice API.

Or 4 ways, if you count "rebuilding the buffer from scratch" :)

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[karan bhatia]

But the reflection based API is still experimental? Also, for building a new flat buffer from scratch, can we reuse "parts" of the existing flatbuffer. (I think this still requires reflection though, right?)

--
You received this message because you are subscribed to a topic in the Google Groups "FlatBuffers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flatbuffers/wvHpzrWL43w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flatbuffers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Facebook | Github | LinkedIn

[Wouter van Oortmerssen]

The reflection API is not experimental in the sense that it has been used extensively (in C++), so we have some faith in that what is there works. It does not support every possible form of mutation though (e.g. it can't add a new field to a table). It is also a somewhat difficult to use API.

You can use reflection to copy a table (and all its children) from an existing buffer to a new one being constructed, yes. To do that without reflection, you have to store it as a nested FlatBuffer, such that you can use byte array copying.

[karan bhatia]

You can use reflection to copy a table (and all its children) from an existing buffer to a new one being constructed, yes. To do that without reflection, you have to store it as a nested FlatBuffer, such that you can use byte array copying.

By a nested flatbuffer, you mean just copying the raw bytes of one flatbuffer into another? I saw the nested_flatbuffer attribute at some places on the group, but I can't seem to find any documentation.  Can you point to some? Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "FlatBuffers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flatbuffers/wvHpzrWL43w/unsubscribe.

To unsubscribe from this group and all its topics, send an email to flatbuffers...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Facebook | Github | LinkedIn

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.

[karan bhatia]

Nevermind! Found the info. Thanks.