I don't understand what you're saying about speed, protocol buffers were designed by Google to satisfy three requirements:
My complaint here is using XML as the yardstick of efficiency. It is hardly the most efficient data protocol format, but the advantages it does offer and the typical application which uses XML doesn't necessarily need the hyper-efficient data formatting either. I'm not disputing what Google has done here either, as it gives a sort of XML-like data protocol framework with increased efficiency, including CPU speed. It just doesn't solve all of the problems for everybody and it shouldn't be viewed as the ultimate solution for programming either.
I guess I'm sort of comparing an efficient data framework to programming in a high level language like C or Python vs. Assembly language. Assembly programming is by far and away more efficient, but it does take some skill to be able to program in that manner. It is also something very poorly (if at all) taught by most computer programming courses of study.
I wouldn't have used XML as a good indicator of performance personally, however it's the only numbers presented on the protobuf website. I might throw together a test using the C# implementation of protocol buffers
to get some numbers for protocol buffers vs hardcoded binary packets. However, I suspect speed isn't *really* a problem here, the serialisation time is on the scale of hundreds of nanoseconds - not a problem!
As for size, I suspect protocol buffers are going to be smaller than a handwritten packet layout by satoshi for a couple of reasons:
1) Bitcoin includes reserved fields for forwards compatibility, ptocol buffers don't
2) Protocol buffers include complex things like variable length encoding etc, which would be a silly micro optimisation for Satoshi to include, but comes for free with protocol buffers (and can significantly decrease the size of a packet)
3) Losing a couple of bytes on the size of a packet (if, indeed packets do get bigger, I suspect they won't) but gaining cross language compatibility, standardisation of the packet layout, significant ease of use in code AND forwards compatibility is a *very* good tradeoff.