Is the Java implementation for FlatBuffer's zero-allocation?

Question

My Java application is storing Protobuf messages in a database. The application is fast, but it could be made faster because not all parts of the messages are always used, causing wasted CPU cycles on unneeded data. Also, some messages have tree-like structures, causing more memory to be allocated than I'd like.

After doing some research, it seems FlatBuffers would be a nice replacement since it's claiming that it's zero-allocation/zero-parse. However, the benchmarks have been ran against C++. My application is written in Java. Is the Java implementation for FlatBuffer's still fast and is it still zero-allocation/zero-parse?

Answer 1

It tries to be as close to zero-allocation as possible, but this is not entirely possible.

For example, the accessor objects that are values in C++ (and C#) are an allocation in Java. However, they can be re-used across multiple objects, so their cost can be low, for a bit more code complexity.

Worse is strings, which are UTF-8 in FlatBuffers, but Java doesn't support UTF-8 directly. So if you want to access it as a String it has to be converted, and allocated. You can alternatively access it as a UTF-8 ByteBuffer but there's very few APIs where this is useful.

However, if not all parts of the data are used, or used incrementally, this is still a huge gain over unpacking/allocating everything at once.