Live data from Hacker News

Bebop: An Efficient, Schema-Based Binary Serialization Format

rainway.com

11–20 of 60 posts

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#13
post #8
post #5

> Our evaluation of other solutions found poor client-side serialization performance, large run-time overhead, poor browser support, and different trade-offs that drove us to create Bebop. Soo... cap'n proto?

There's also FlatBuffer, which is also specifically made for Gaming application by Google.

Came up with a list of IDL alternatives for a question recently, perhaps relevant/interesting [1].

1: https://cs.stackexchange.com/questions/129904/does-there-exi...

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#15
post #8

Earlier quoted context omitted.

There's also FlatBuffer, which is also specifically made for Gaming application by Google.

Originally created by Wouter van Oortmerssen http://strlen.com/

Wow, that's a name I haven't heard in 30-odd years, I loved programming in AmigaE in the 90's!

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#17
post #15

Earlier quoted context omitted.

Originally created by Wouter van Oortmerssen http://strlen.com/

Wow, that's a name I haven't heard in 30-odd years, I loved programming in AmigaE in the 90's!

In that case I think you're going to enjoy checking out his website! He's done quite a few cool things in the meantime

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#18
post #7
post #2

How does this compare performance-wise with Arrow, designed for zero-copy usage?

They have different use-cases: * Arrow is columnar, batch-oriented, geared toward high throughput. * Bebob is record-oriented, similar to Avro, Protobuf or JSON, geared toward low latency.

Also interesting to note that Arrow itself uses FlatBuffers for its schema data.

https://arrow.apache.org/docs/format/Columnar.html

Re: Bebop: An Efficient, Schema-Based Binary Serialization Format

#19
The article doesn't mention at all how those speedups have been achieved, what tradeoff the format makes and what it is optimized for - which would be the actually interesting part.

A link to the benchmark code and description of the data would be nice.

It also doesn't show data for FlatBuffer, which is often a lot faster and leaner than ProtoBuf, or for Capt'n Proto.

ProtoBuf is not exactly known for amazing performance or very optimal client implementations across the various languages.

By all means, create a new serialization format, why not. But with so many options to chose from, I would require really strong justification internally.

Post reply on HN