Binary Reader for C / C++? FlatBuffers!

kxs

Hello,
We faced with the problem that skeleton data stored in JSON takes a lot of time to be read at runtime.
There are few discussions about that and sometimes Nate even promises to make some reader available for C / C++.
What if you won't make a new reader but use an existing binary format called FlatBuffers?
More info: https://google.github.io/flatbuffers/index.html
It's extremely fast and memory efficient! It also provides a great flexibility with backward compatibility!
And finally it's been already implemented for multiple languages: https://google.github.io/flatbuffers/flatbuffers_support.html
Actually we have already used it for our internal data and found it really useful.
Please think about this. The performance the JSON-reader shows really sucks 🙂

Nate

JSON is the wrong technology if you care about speed, so it's not much of an issue if it is slow.

FlatBuffers provides features that the Spine runtimes don't need, such as compatibility. Our own binary format is smaller and faster. I admit we are a bit late getting it done for spine-c, but it will happen! 🙂

jjsh

I'd rather think twice before talking i don't need backward compatibility... Currently it's a mess when new version of Spine is released, but runtime still not and there is no possibility to load newly exported data. There are a lot of such moments had happened at this year. Our work had blocked for a weeks each time.

I personaly know how flatbuffers is fast for C/C++ and python, also i aware how it fast for C#. I know how it designed inside. So i just can't belive that format of binary deserialization can be faster than flat-coverage format. I'm already investigated "SkeletonBinary.java" from "com.esotericsoftware.spine".
Using flatbuffers for C/C++ you don't need deserialization step more. Data becomes ready to work once it plainly placed from file to memory and covered by flatbuffers.

Of course flatbuffers is not a silver bullet for any case. Also i don't know your thoughts about expansion to other languages.
All i suggest you is to think twice about implementing another binary format with strict features instead using of popular, flexible and extendible library.

Nate

Don't worry, we tend to think multiple times. 😉

I'll explain how the Spine editor and runtimes versioning should work: Your animators freeze their editor version to match the runtimes version your developers are using. The versions of both the editor and runtimes are updated at the same time. After updating to a newer version, all the skeleton data is exported from the project files with the new editor version.

If the editor version or runtime version is updated separately, maybe it works, maybe it breaks. Unless you enjoy that sort of chaos, this must be avoided.

Compatibility happens at the Spine project file level. Placing this burden on the runtimes would be messy and provides no advantages. Forward compatibility (using older runtimes and newer data) doesn't help. Even if the old runtime can read newer data, it doesn't know about newer features and so is very unlikely to be able to render what data it can read correctly. Backward compatibility (using newer runtimes with older data) means you can update your runtimes version without updating your editor version, but there is no good reason to do this. If you update your runtimes, simply update your editor to match. Exporting your data again is easy. It can be automated or done from the command line in batches.

FlatBuffers are not magic. There are costs for the features it provides. Our format is faster because it does only what it needs and it can make assumptions about the data that a general purpose serialization library cannot. A general purpose solution would reduce the deserialization code needed in the Spine runtimes, but this is not an important factor and would come with the sacrifice of both speed and size.

jjsh

Nate wrote
Your animators freeze their editor version to match the runtimes version your developers are using. The versions of both the editor and runtimes are updated at the same time.

Wow! It means we must carely and fearly look at each update of Spine? First look is there updated runtimes which support all new features and only after that update Spine editor? Sounds kidding. It's can't be considered as production decision. It will be better to release both editor and runtimes at same time. And yes, it will be better to release runtimes for all languages at same time with editor. If you woun't care about compatibility, only such decision can be considered as production one.

Nate wrote
FlatBuffers are not magic. There are costs for the features it provides. Our format is faster because it does only what it needs and it can make assumptions about the data that a general purpose serialization library cannot.

I wish to see some facts about it. Why binary deserialization format can be faster than flat-coverage one? How per-byte reading can be faster than tree of pointers to ready-to-read data?

What we have now here: https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-c
SkeletonData is the tree of pointers. It's creation costs definitely huge time cuz not only of json reading, but cuz of that ton of malloc operations. Even if i will rewrite current json parser, time consumed to skeleton data creation still will be dramaticaly huge.
What flatbuffers can give us here. Not so much, but only binary file with initially baked skeleton data. And now i don't need to allocate memory, i just need to read file into memory. It's totally overwhelming performance over data deserialization.
Both skeleton data and skeleton can be baked into such file, each skeleton can be copied into RW memory to give it possibility of modification.

Moreover, flatbuffers formats frequently used as network data protocol.

I frequently design data formats using flatbuffers. I use it as scene graph format in my framework, but not only there. Models, resource packs, obfuscated objects for data-driven. I use a lot of file formats and don't care about time it consume on load cuz it consumes very small time. I have designed plugins for 3D editors, Particle editors, Photoshop, a lot of small internal tools. All of them uses flatbuffers for saving files.
Every such file represents the ready to use image of dynamic memory.

Nate

jjsh wrote
Wow! It means we must carely and fearly look at each update of Spine? First look is there updated runtimes which support all new features and only after that update Spine editor? Sounds kidding.

Updating any dependency blindly and hoping everything will be OK is foolish.

It will be better to release both editor and runtimes at same time.

I appreciate this may be better for your particular use case, but it would make editor users (animators) wait until all runtimes have been updated. By releasing editor updates ahead of runtimes, animators have the option to begin using new features as soon as possible. Not all animators are blocked by runtime support. Some are exporting to images/video and some don't mind continuing their work until the runtimes are updated.

I wish to see some facts about it. Why binary deserialization format can be faster than flat-coverage one? How per-byte reading can be faster than tree of pointers to ready-to-read data?

FlatBuffers are lazy, they push the work to be done until later. It's true that in C this work can be minimal because any block of memory can be treated as a type, but other languages don't have this ability and need to perform allocation on access. Users of such an API need to be aware it is doing this, as access can be expensive. Also, the generated FlatBuffer API doesn't lend itself to adding richer behavior. For these reasons the generated API doesn't make for good first class citizens in an object model. If we were to copy the data out of the generated API then the laziness is gone and we'd end up with a more complex version of what we already have.

I frequently design data formats using flatbuffers. I use it as scene graph format in my framework, but not only there. Models, resource packs, obfuscated objects for data-driven. I use a lot of file formats and don't care about time it consume on load cuz it consumes very small time. I have designed plugins for 3D editors, Particle editors, Photoshop, a lot of small internal tools. All of them uses flatbuffers for saving files.

FlatBuffers are a neat hammer, but not every problem is a nail.

jjsh

So your opinion flatbuffers can't be used is that for languages with managed memory it allocate objects per any access? This is the problem of languages with managed memory, but not the problem of C/C++. You already use deserialization in java, what prevent you deserialize flatbuffers into your objects on such languages?
Initially solid approach can be tightly separated to fit purposes of each platform or language. Purposes of C/C++ are performance and low memory allocation/consumption.

Currently i must use concurrency to load skeletons. 1.2-1.5sec per skeleton definetly slow (over 4Mb pretty-printed json). Even with optimized json parser skeleton creation consumes up to 800msec. But loading flatbuffers with 2.5Mb size (loading + verification) costs me at last 60msec (and 12msec without verification). And i can load it without concurrency...

Nate

jjsh wrote
So your opinion flatbuffers can't be used is that for languages with managed memory it allocate objects per any access?

A generated FlatBuffer API is a poor first class citizen in an object model. I explained this and more in my last post.

jjsh wrote
1.2-1.5sec per skeleton definetly slow (over 4Mb pretty-printed json). Even with optimized json parser skeleton creation consumes up to 800msec.

The binary format is for size and speed. There is little usefulness in measuring JSON loading speeds, it's the wrong tool if speed is a concern.