> 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.
It's more like I started from "Let's design a message format that can be passed through shared memory or mmap()ed with literally zero copies", and then arena allocation was a natural requirement. :)
> Since your approach is much more focused, you have been able to turn out usable results orders of magnitude faster than I have.
To be fair, the fact that I'm working on it full-time -- and with no review, approval, or other management constraints of any kind -- helps a lot. :) (Down side is, no income...)
> 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.