Yes but that actually has better performance than writing bytes directly to the DataOutput. I tested this with JavaBinCodec and I don't think performance will be very different here (see JMH benchmark results in
SOLR-7971). Presumably, the huge amount of invocations of writeByte don't perform well compared to setting a byte in a scratch array directly.
Its unclear to me the complexity is worth it. The data used in the benchmark is 100% latin-1 (completely english), which certainly isn't representative of reality, so the benchmarks don't mean anything to me.
One thing to keep in mind is it only affects writes from string fields on flush, during merging, bulk copying can kick in, and even in the worst case where that can't happen, we really shouldn't be taking this codepath anyway, we should just do byte -> byte for string fields
So I'm not sure if the optimization (especially for 10MB documents which is a ridiculous case) is really that powerful? We have to be extremely careful here because with these kind of optimizations, any bug -> data corruption.