Skip to content

Comparison With Google FlatBuffers

Jump to bottom
James Courtney edited this page Nov 2, 2022 · 7 revisions

FlatSharp is a mostly independent implementation of the FlatBuffer format. This means implementations of:

  • Code gen
  • Runtime

There is good and bad about this.

  • Good: FlatSharp is highly optimized for C# and C# scenarios
  • Good: FlatSharp can include features that only make sense in C#
  • Bad: FlatSharp can sometimes trail the canonical implementation as new features are added.
  • Good/Bad: FlatSharp uses the official flatc compiler as an FBS parser, so custom grammar extensions are not possible. However, there is no risk of FlatSharp and flatc having different opinions about the semantics of a given FBS file, so compatibility is increased.

In terms of FlatBuffer features, there is a ton of overlap between the implementations:

  • Tables, Structs, Vectors, Unions, Strings, Scalars, and Enums
    • FlatSharp only allows a single type to be present in a union once (ie, Union<TableA, TableB, TableA> is unsupported).
  • Default values for scalars, including optional scalars
  • Sorted Vectors
  • Shared strings
  • Vtable deduplication
  • Vectors of Unions
  • Fixed-Size struct vectors (struct Foo { Data : [ulong:16]; })

Notable features FlatSharp does not support:

  • FlexBuffers
  • force_align attribute
  • Structs as root objects (only tables can be roots); this is a FlatCC feature only. Google FlatBuffers also does not support this.

Notable features Google Flatbuffers does not support (C# only):

  • gRPC
  • Different deserialization modes. The Google implementation is always Lazy by default. When using the object-api switch in flatc, then it is always Greedy.
  • An equivalent to the IIndexedVector abstraction over sorted vectors

Implementation Differences

FlatSharp and the main FlatBuffer library differ substantially in how they are implemented:

Buffer Build Direction

FlatSharp builds buffers front-to-back, while the Google implementation builds them back-to-front. Interestingly, the leaf nodes of the object graph tend to end up at the end of the buffer in both implementations. However, the serialized bits will not be identical between the two implementations. The FlatBuffer format is flexible enough to allow many different binary representations of the same message.

Support for Memory<T> and Span<T>

FlatSharp was built from the ground up to have first-class support for Memory<T> and Span<T>. The Google implementation includes some support for Span<T>, but the main buffer builder still depends on byte arrays.

Clone this wiki locally