5 ms·

1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default

by doh 10y ago

1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time 3) protobuf generates incredibly large serialization/deserialization support coce for each template. For some languages like Python in can be in hundreds of kilobytes. Cap'n proto messages are significantly smaller There is more for CnP but Protobuf has much better support and is by default used in projects like gRPC. Also new CnP is lacking speed in new development in comparison to Protobuf. But I'm using in one of my side projects and I'm very happy with it

hueving 10y ago
Thanks. Those are pretty significant advantages. These things should be on the home page of the project. That's how smaller projects gain share.
- andrewstuart2 10y ago
  The first one is, but as the obviously hyperbolic "infinitely faster" claim.
skybrian 10y ago
re: "Doesn't encode/decode messages" Does this mean that individual fields are encoded/decoded lazily?
- kentonv 10y ago
  Well, you could look at it that way. But the "encoding" is the same encoding that an "int" field in a struct uses, and "decoding" it is a trivial load instruction.
  - lastofus 10y ago
    At what point is byte ordering handled?
    - kentonv 10y ago
      The format is little-endian, so it's necessary to use a little-endian load instruction, which almost all architectures (including most big-endian architectures) have. (But every widely-used arch these days is LE.)
euyyn 10y ago
(2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.
- doh 10y ago
  Depends on the use case. For instance if you're mapping the data to database, you can't send null variables. Or you store the defaults (waste of space) or you send it as another type. In our case we've now over 1T of rows. Storing default variables would be incredibly inefficient and expensive.
  - euyyn 10y ago
    I'm not understanding your case much. Proto3 does not serialize zeros/false, precisely because it'd be a waste without a benefit. After deserialization, the value is as equal to zero as if the zero had been written on the wire or on disk. Why would you want to store that? Is nullability of primitive types what you're missing? As in, having a boolean value that can be true, false, or null. If you need that, defining your field as google.protobuf.BoolValue instead of bool gives you that (same with the other primitive types: https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto https://github.com/google/protobuf/blob/master/src/google/pr... ). But making primitive types never null aligns proto3 with most programming languages, making the generated code more idiomatic and performant.
nurettin 10y ago
I use protobuf-generated RTTI for the purpose of doing endpoint SQL storage of the messages. (tables, columns, foreign keys, insert/select statements are all auto-generated from the protobuf message) using C++. Does capnproto provide similar RTTI information to walk through properties or recurse into other messages?
- kentonv 10y ago
  Absolutely. I was the one who originally designed the Protobuf RTTI (aka "reflection") interface, after all... :) It's actually considerably easier to implement for Cap'n Proto since the in-memory objects are actually backed by byte buffers containing the wire format. No need to compute offsets of class members (which technically violates the C++ standard though it works on all compilers).

by doh 10y ago

hueving 10y ago

Thanks. Those are pretty significant advantages. These things should be on the home page of the project. That's how smaller projects gain share.

andrewstuart2 10y ago
The first one is, but as the obviously hyperbolic "infinitely faster" claim.

skybrian 10y ago

re: "Doesn't encode/decode messages" Does this mean that individual fields are encoded/decoded lazily?

kentonv 10y ago
Well, you could look at it that way. But the "encoding" is the same encoding that an "int" field in a struct uses, and "decoding" it is a trivial load instruction.
- lastofus 10y ago
  At what point is byte ordering handled?
  - kentonv 10y ago
    The format is little-endian, so it's necessary to use a little-endian load instruction, which almost all architectures (including most big-endian architectures) have. (But every widely-used arch these days is LE.)

euyyn 10y ago

(2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.

doh 10y ago
Depends on the use case. For instance if you're mapping the data to database, you can't send null variables. Or you store the defaults (waste of space) or you send it as another type. In our case we've now over 1T of rows. Storing default variables would be incredibly inefficient and expensive.
- euyyn 10y ago
  I'm not understanding your case much. Proto3 does not serialize zeros/false, precisely because it'd be a waste without a benefit. After deserialization, the value is as equal to zero as if the zero had been written on the wire or on disk. Why would you want to store that? Is nullability of primitive types what you're missing? As in, having a boolean value that can be true, false, or null. If you need that, defining your field as google.protobuf.BoolValue instead of bool gives you that (same with the other primitive types: https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto https://github.com/google/protobuf/blob/master/src/google/pr... ). But making primitive types never null aligns proto3 with most programming languages, making the generated code more idiomatic and performant.

nurettin 10y ago

I use protobuf-generated RTTI for the purpose of doing endpoint SQL storage of the messages. (tables, columns, foreign keys, insert/select statements are all auto-generated from the protobuf message) using C++. Does capnproto provide similar RTTI information to walk through properties or recurse into other messages?

kentonv 10y ago
Absolutely. I was the one who originally designed the Protobuf RTTI (aka "reflection") interface, after all... :) It's actually considerably easier to implement for Cap'n Proto since the in-memory objects are actually backed by byte buffers containing the wire format. No need to compute offsets of class members (which technically violates the C++ standard though it works on all compilers).