Do we suboptimally call ByteBuffersDataOutput.toDataInput()?

[dungba88]

Description

See this comment: #12624 (comment)

I wonder: are there other places in Lucene that might fall prey to this performance trap (calling toDataInput frequently while continuing to append bytes to the DataOutput)? FreqProxTermsWriter seems to use this for each term to re-read the postings (maybe for the static sort use case).

[mikemccand]

At least we should add a warning to the javadocs here.

And we should audit other places that are frequently calling .toDataInput() (e.g. block tree terms dict writing?).

This method is surprisingly slow compared to simply juggling our own byte[] under the hood, at least in FST's (well, Test2BFSTs) usage.

[dweiss]

I don't think it was ever meant to be called repeatedly in fast bursts. It was meant to provide a direct reader for previously written buffers, once the writing is completed.

[dweiss]

Also, not sure why it's slow - perhaps because of the wrapping in read-only buffers when toBufferList is called? If so, then this could be internally tweaked by calling toWriteableBufferList inside toDataInput (since we know data input is not going to be messing with the buffers...).