Hi Wes,Yes, you can argue that certain use cases might require a copy where with protobufs they could be designed differently and avoid that copy.In my experience, most real-world uses of protobufs construct the whole message just before sending. Whether or not this construction makes sense to call a "copy" depends on the use case, but in any case that's not the copy that Cap'n Proto is claiming to avoid.If you are trying to store some in-memory state that changes over time, and you want to occasionally dump that state to disk / network, and you would normally have been happy keeping the state in a protobuf object, then, yes, with Cap'n Proto you now probably need to keep the state in some other structure and do an extra copy every time you dump it. However, this copy will still be a lot faster than protobuf encoding, since it's just a lot of loads and stores with few branches.
Actually, though, if you're careful, you can in fact store your state in a Cap'n Proto structure. You just have to understand how Cap'n Proto manages memory. If the changes you're making to your state don't ever involve removing whole objects from the message tree, then there's no problem. Or, if you're willing to occasionally do a sort of "garbage collection" pass by making a copy of the whole message into a new MessageBuilder, then that can also solve the problem -- and may in fact turn out to be a lot more efficient than Protobuf memory management. For instance, you could do this "GC" pass every time the space occupied by the message doubles. This would give you amortized performance that's likely better than relying on malloc(). But you have to understand what you're doing, which is why we don't usually recommend it. :)
Protocol buffers are much better with mutable data.