> Binary HTTP/2 headers can be parsed a lot faster than plain text
Any advantage in parsing speed that binary has is going to be so small that it won't matter. On modern out-of-order, speculatively executing hardware, wasted CPU times usually mis-predicted branches and waiting for data to be loaded into the L1 cache. The handful of extra instructions to convert an integer from ASCII to a register-sized-int is minimal, and can be "free" if it fits in the L1 cache.
> (HTTP0.x/1.x)
There's you're problem - HTTP/1.x was not designed to be fast; it was designed to allow simple implementations (most headers can be ignored) and arbitrary ad-hoc extensions. It is entirely possible to make a replacement for HTTP that is much faster to parse than HTTP/1.1. A protocol being "text base" is orthogonal to that protocol allowing annoying-to-parse arbitrary size fields. A binary protocol can be just as slow to parse if it is badly designed.
Any advantage in parsing speed that binary has is going to be so small that it won't matter. On modern out-of-order, speculatively executing hardware, wasted CPU times usually mis-predicted branches and waiting for data to be loaded into the L1 cache. The handful of extra instructions to convert an integer from ASCII to a register-sized-int is minimal, and can be "free" if it fits in the L1 cache.
> (HTTP0.x/1.x)
There's you're problem - HTTP/1.x was not designed to be fast; it was designed to allow simple implementations (most headers can be ignored) and arbitrary ad-hoc extensions. It is entirely possible to make a replacement for HTTP that is much faster to parse than HTTP/1.1. A protocol being "text base" is orthogonal to that protocol allowing annoying-to-parse arbitrary size fields. A binary protocol can be just as slow to parse if it is badly designed.