Re:Revisiting Apple Notes (6): The Protobuf
by wahern on Monday September 21, 2020 @05:20PM
(#24548613)
I've written zero-copy implementations (as much as was possible) for DNS, MIME, RTSP/RTP, SMTP, and others. Locality is far more important to performance. Generic zero-copy APIs often have too much indirection, and for short messages or messages with many distinct fields, generating all those pointers can cause more data churn than simple copies. And while zero-copy makes the most sense for messages with large blobs, if you have to buffer the entire message you're again losing data locality, whereas a streaming architecture can be even more performant even with copies (and even because of the copying) when you can keep your working set small and hot.
IME, there's simply no getting around the fact that if you want better performance, efficiency, and/or latency, you have to design your entire stack holistically. A library promising a generic API with a supposedly generic "optimization" is often already suboptimal, and architecting an application with that mindset (e.g. trying to push all the hard parts behind a generic getter/setter API) makes the suboptimality grow non-linearly.
I agree about ASN.1. The ASN.1 specifications are well written and everything is very well thought out (even though it's not always obvious why without the benefit of hindsight). Though, for a long while they weren't freely available, officially or unofficially. Thankfully that's changed (not sure precisely when that happened), but it cost them a lot in terms of mindshare and was a big reason, I suspect, for the horrible open source tooling both then and now.
IME, there's simply no getting around the fact that if you want better performance, efficiency, and/or latency, you have to design your entire stack holistically. A library promising a generic API with a supposedly generic "optimization" is often already suboptimal, and architecting an application with that mindset (e.g. trying to push all the hard parts behind a generic getter/setter API) makes the suboptimality grow non-linearly.
I agree about ASN.1. The ASN.1 specifications are well written and everything is very well thought out (even though it's not always obvious why without the benefit of hindsight). Though, for a long while they weren't freely available, officially or unofficially. Thankfully that's changed (not sure precisely when that happened), but it cost them a lot in terms of mindshare and was a big reason, I suspect, for the horrible open source tooling both then and now.