On 2021-01-29 Brett Okken wrote: > There are several places where single byte writes are being done > during compression. Often this is going to an OutputStream with > synchronized write methods. Historically that has not mattered much > because of biased locking. However, biased locking is being > removed[1]. These changes will batch those writes up to a small > buffer.
LZMA2OutputStream: I have committed a functionally similar patch. Thanks! BlockOutputStream: The ByteBuffer code replacing ByteArrayOutputStream is more complex than the original code. For example, manually resizing a buffer may be useful when performance is important but in this class performance doesn't matter. IndexEncoder: If there were a huge number of Blocks and thus Records, it would allocate memory to hold them all. It could be nicer to use something similar to BufferedOutputStream which would always use the same small amount of memory. java.io.BufferedOutputStream cannot be used because its close() and flush() methods call flush() on the underlying output stream and here it's counter-productive. The reading side in IndexDecoder and IndexHash could be similarly optimized to use a buffered input class that takes an argument to limit how many bytes it may read from the underlying InputStream. If the Index* classes are optimized, then the CRC32 writing in XZOutputStream, IndexEncoder, and BlockOutputStream may be worth optimizing too. It's important to keep in mind that these make no real difference if the application buffers the input or output with BufferedInputStream or BufferedOutputStream. In some use cases it may be impractical though, and then the small reads and writes may hurt if each read/write results in a syscall or even sending packets over network; such overheads can be much larger than locking. I put these optimizations in the "nice to have" category. Something could be done to make the code better but it's not urgent and so these won't be in the next release. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
