4 ms·

Hi kentonv! I have a tangential question for you, if you don’t mind. I brought up your capnproto with a few friends at work, while chatting about the profiling

by gen220 7y ago

Hi kentonv! I have a tangential question for you, if you don’t mind. I brought up your capnproto with a few friends at work, while chatting about the profiling data of our services (mostly CPU-bound, mostly on protobuf de-/encoding). After convincing ourselves that language-agnostic “zero-cost” requests weren’t completely magical, and that the whole promise thing is very useful, we got to wondering... Do you think it’s possible, that gRPC/proto could evolve in a non-total-rewrite way to earn the benefits offered by capnproto? I figure you’d be best positioned to answer that kind of question, having worked so intimately on both! :) We have enjoyed getting to know and using gRPC and proto, I also want to thank you for your work! capnproto is an inspiring solution to a prima facie unsolvable problem, I hope to see it succeed more universally, or at least inspire a proto4. :) Thank you again!

Youden 7y ago
I'm not entirely clear on whether this Github issue would bring feature-parity with Cap'n'proto but apparently Google already has a zero-copy API for Protocol Buffers internally: https://github.com/protocolbuffers/protobuf/issues/1896 https://github.com/protocolbuffers/protobuf/issues/1896
- kentonv 7y ago
  I originally wrote the "zero copy" support in proto2, long before I created Cap'n Proto. What Protobuf means by "zero copy" is much more limited than what Cap'n Proto means. Protobuf's "zero copy" applies only to individual string (or "bytes") fields. The effect is that when you call the getter for that field, you get a pointer to the string inside the original message buffer, rather than a copy allocated on the heap. The overall message structure still needs to be parsed upfront and converted into an object tree on the heap (which I count as a copy). Cap'n Proto is very different. Every Cap'n Proto object is actually a pointer into the original message buffer. Accessing one element of a large array is O(1) -- the previous (and subsequent) elements don't need to be examined at all. Similarly with structs, each field is located at a known fixed offset from the start of the struct, so can be accessed without examining other fields. Protobuf inherently cannot do this; there is no way to know where a field is located without first parsing all previous fields in the same message.
kentonv 7y ago
I think Protobuf fundamentally can't achieve zero-copy parsing without changing the underlying encoding. That said, zero-copy parsing only provides a significant real-world benefit in certain use cases. For the use case of RPC over a network -- especially over the internet -- zero-copy parsing has minimal benefit. The places where zero-copy parsing can be a big win are when it means you can mmap() a very large file, or for IPC in shared memory. On the other hand, Promise Pipelining -- and, more generally, object-capability RPC -- could definitely be added to gRPC. In fact, the very first iteration of Cap'n Proto was a Protobuf-based RPC system that used the same service definition syntax that gRPC now uses. "Cap'n Proto" at the time meant "capabilities and protobuf". (That version of the project was short-lived and shares no code at all with the current Cap'n Proto.) However, I don't think gRPC is likely to add ocaps unless and until the model proves itself by gaining wide popularity elsewhere. It doesn't make sense for gRPC to take the risk of adding a big, new, experimental feature which they'll be forced to support forever when the demand hasn't been proven yet. Ocaps are gaining a lot of popularity lately (with major new tech like Fuschia and WASI being capability-based) but I think there's still further to go before it would make sense for gRPC to adopt it.

by gen220 7y ago

Youden 7y ago

I'm not entirely clear on whether this Github issue would bring feature-parity with Cap'n'proto but apparently Google already has a zero-copy API for Protocol Buffers internally: https://github.com/protocolbuffers/protobuf/issues/1896 https://github.com/protocolbuffers/protobuf/issues/1896

kentonv 7y ago
I originally wrote the "zero copy" support in proto2, long before I created Cap'n Proto. What Protobuf means by "zero copy" is much more limited than what Cap'n Proto means. Protobuf's "zero copy" applies only to individual string (or "bytes") fields. The effect is that when you call the getter for that field, you get a pointer to the string inside the original message buffer, rather than a copy allocated on the heap. The overall message structure still needs to be parsed upfront and converted into an object tree on the heap (which I count as a copy). Cap'n Proto is very different. Every Cap'n Proto object is actually a pointer into the original message buffer. Accessing one element of a large array is O(1) -- the previous (and subsequent) elements don't need to be examined at all. Similarly with structs, each field is located at a known fixed offset from the start of the struct, so can be accessed without examining other fields. Protobuf inherently cannot do this; there is no way to know where a field is located without first parsing all previous fields in the same message.

kentonv 7y ago

I think Protobuf fundamentally can't achieve zero-copy parsing without changing the underlying encoding. That said, zero-copy parsing only provides a significant real-world benefit in certain use cases. For the use case of RPC over a network -- especially over the internet -- zero-copy parsing has minimal benefit. The places where zero-copy parsing can be a big win are when it means you can mmap() a very large file, or for IPC in shared memory. On the other hand, Promise Pipelining -- and, more generally, object-capability RPC -- could definitely be added to gRPC. In fact, the very first iteration of Cap'n Proto was a Protobuf-based RPC system that used the same service definition syntax that gRPC now uses. "Cap'n Proto" at the time meant "capabilities and protobuf". (That version of the project was short-lived and shares no code at all with the current Cap'n Proto.) However, I don't think gRPC is likely to add ocaps unless and until the model proves itself by gaining wide popularity elsewhere. It doesn't make sense for gRPC to take the risk of adding a big, new, experimental feature which they'll be forced to support forever when the demand hasn't been proven yet. Ocaps are gaining a lot of popularity lately (with major new tech like Fuschia and WASI being capability-based) but I think there's still further to go before it would make sense for gRPC to adopt it.