| Generally a fair analysis. A few comments/corrections: > For example, it appears that the in-memory format was not sufficiently flexible for Python to wrap it directly, so the Python extension does in fact have a parse step. This is not correct. The Python wrapper directly wraps the C++ interface. You might be confused by Jason's claim that "The INFINITY TIMES faster part isn't so true for python", but this was apparently meant as a joke. It is true, though, that the constraints of arena-style allocation (which Cap'n Proto necessarily must use to be truly zero-copy) mean that working with Cap'n Proto types is not quite as convenient as protobufs, although most users won't notice much of a difference. Lists not being dynamically resizable is the biggest sore point, though most use cases are better off not relying on dynamic resizing (it's slow), and the use cases that really do need it can get around the problem using orphans (build an std::vector<Orphan<T>>, then compile that into a List<T> when you're done). OTOH, over the years, many people have requested the ability to use arena allocation with Protobufs due to the speed benefits, especially with Protobufs being rather heap-hungry. I always had to tell them "It would require such a massive redesign that it's not feasible." And yes, there is the trade-off of padding on the wire. You have to decide whether your use case is more limited by bandwidth or CPU. With Cap'n Proto you get to choose between packing (removing the zeros, at the cost of a non-free encode/decode step) and not packing (infinitely-fast encode/decode, larger messages). For intra-datacenter traffic you'd probably send raw, whereas for cross-internet you'd pack. Protobufs essentially always packs without giving you a choice. And because it generates unique packing code for every type you define (rather than use a single, tight implementation that operates on arbitrary input bytes), Protobuf "packing" tends to be slower. |
> OTOH, over the years, many people have requested the ability to use arena allocation with Protobufs due to the speed benefits, especially with Protobufs being rather heap-hungry. I always had to tell them "It would require such a massive redesign that it's not feasible."
Yes totally, I agree that arena allocation is great. I think we both agree on this point, though we've taken two different paths in attempting to solve it.
Your approach is to say that arena allocation can be made pretty convenient, and sparse messages can compress really well, so let's design a message format that is amenable to arena allocation and then implement a system that uses this format both on-the-wire and in memory.
My approach is to say that we can solve this (and many other related problems) by decoupling wire formats from in-memory formats, and having the two interoperate through parsers that implement a common visitor-like interface. Then a single parser (which has been optimized to hell) can populate any kind of in-memory format, or stream its output to some other wire format. Of course this will never beat a no-parser design in speed, but the world will never have all its data in one single format.
I think of these two approaches as totally complimentary; to me Capn Proto is simply another key/value serialization format with a particular set of nice properties, and I want it to be easy to convert between that and other formats.
Since your approach is much more focused, you have been able to turn out usable results orders of magnitude faster than I have. I'm spending time implementing all of the various protobuf features and edge cases that have accumulated over the years, while simultaneously refining my visitor interface to be able to accommodate them while remaining performance-competitive with the existing protobuf implementation (and not getting too complex). As much as I believe in what I'm doing, I do envy how you have freed yourself from backward compatibility concerns and turned out useful work so quickly.