3

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?

user1428945
  • 339
  • 1
  • 13

2 Answers2

3

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.

Aardappel
  • 5,559
  • 1
  • 19
  • 22
  • Might be worth adding that modern JVMs perform escape analysis, and may allocate objects on the stack if the object does not escape the calling stack frame. Reusing objects is therefore not necessarily faster, and may actually turn out to be slower due to increased cache misses. – meriton May 28 '17 at 19:02
2

Judging from the library code, both parsing and object allocation occur lazily upon property access.

As for speed, I can't imagine this being significantly slower than fetching the data from the database in the first place - but feel free to benchmark it :-)

meriton
  • 68,356
  • 14
  • 108
  • 175