(translation www.java-performance.com) improve Java program performance--JDK (iv)

Java.io.ByteArrayOutputStream:java.io.ByteArrayOutputStream, java.nio.ByteBuffer:why you should Bytearrayoutputstream in the performance critical code.
1. The performance-demanding code uses bytebuffer instead of Bytearrayoutputstream, if you still want to use Bytearrayoutputstream to remove its synchronization.
2. If your function writes some data to an unknown outputstream, first write the data to Bytearrayoutputstream and then use the Bytearrayoutputstream writeto (outputstream) The function is written to the OutputStream. There is a rare scenario where you create a string from a byte stream and remember to use the bytearrayoutputstream.tostring function.
3. In some cases, avoid using the Bytearrayoutputstream.tobytearray function because it duplicates an internal byte array. Especially if your program uses a few grams of memory, the garbage collector will take a significant amount of time to collect these copies.

Java.io.BufferedInputStream and Java.util.zip.GZIPInputStream:java.io.BufferedInputStream, Java.util.zip.GZIPInputStream, Java.nio.channels.FileChannel:some minor performance pitfalls in these, streams.
1. Bufferedinputstream and Gzipinputstream have internal buffers. The default size of the previous one is 8K, and the default size for the latter is 512B. They grow at least 64K in length.
2. Do not use Bufferedinputstream as the input stream for Gzipinputstream, It is good practice to specify a buffer size when constructing gzipinputstream. However, it is still safe to keep a bufferedinputstream.
3. If you have such an object new Bufferedinputstream (new FileInputStream (file)), And often calls its available function (like one or two calls per read), you should consider overriding the Bufferedinputstream.available function. This can greatly improve the speed of reading files.

Performance of various general compression algorithms-some of them is unbelievably fast!: Java.util.zip.GZIPInputStream /Gzipoutputstream/deflateroutputstream/inflaterinputstream, LZ4, snappy:checking performance of various general pur Pose Java compressors.
1. If you feel that the compression data is particularly slow, then try to LZ4 (fast) implementation, it compresses a text file speed can reach the mb/sec, for most applications this speed is basically no obvious feeling. If possible, set the compression buffer size of the LZ4 to its 32M limit, which can be useful (decompression is the same). You can also string up 2 lz4blockoutputstream-s with a 32M-size buffer for greater benefits.
2. If you are limited by the inability to use a third-party library to achieve compression, or want a better compression, try the JDK deflate (lvl=1) codec, the same file it can reach the speed of mb/sec.

Original

Java.io.ByteArrayOutputStream:,: Why do you should does use the java.io.ByteArrayOutputStream java.nio.ByteBuffer ByteArrayOutputStream performance critical code.

• For performance critical code try-to ByteBuffer -use instead of ByteArrayOutputStream . If you still want to use ByteArrayOutputStream -get rid of the its synchronization.
• If you is working on a method which writes some sort of message to unknown OutputStream , always write your message ByteArrayOutputStream to the First and use their writeTo(OutputStream) method after. In some rare cases if you is building a from its String byte representation, does not forget about ByteArrayOutputStream.toString methods.
• In the most cases avoid ByteArrayOutputStream.toByteArray method-it creates a copy of internal byte array. Garbage collecting these copies may take a noticeable time if your application are using a few gigabytes of memory (see Ine Fficient byte[] to String constructor article for another example).

Java.io.BufferedInputStream and Java.util.zip.GZIPInputStream: java.io.BufferedInputStream , java.util.zip.GZIPInputStream , java.nio.channels.FileChannel : Some minor performance pitfalls in th ESE streams.

Tags: High throughput, CPU optimization, memory optimization, data compression.

• both  bufferedinputstream  and  gzipinputstream  have Internal buffers. The Default size for the former one are 8192 bytes and for the latter one are bytes. Generally it worth increasing any of the these sizes to at least 65536.
• do not use a  bufferedinputstream  as a input for a  Gzipinputstream , instead explicitly set  gzipinputstream  buffer size in the constructor. Though, keeping a  Bufferedinputstream is still safe.
• If you have a  new Bufferedinputstream (new FileInputStream (file))  object and your call ITS&NB Sp available  method rather often (for example, once or twice per each input message), consider OVERRIDING&N Bsp bufferedinputstream.available  method. It'll greatly speed up file reading.

Performance of various general compression algorithms-some of them is unbelievably fast!: java.util.zip.GZIPInputStream / GZIPOutputStream / DeflaterOutputStream / InflaterInputStream , LZ4 , Snappy : Checking Performance of various general purpose Java compressors.

Tags: High throughput, CPU optimization, storage optimization, data compression, GZIP, deflate, LZ4, Snappy.

• If you think this data compression is painfully slow and then check LZ4 (FAST) implementation, which are able to compress a te XT file at ~320 mb/sec-compression @ Such speed should is not noticeable for most of applications. It makes sense to increase the LZ4 compression buffer size up to its 32M limit if possible (keep on mind so you'll nee D A similarly sized buffer for uncompression). You can also try chaining 2 LZ4BlockOutputStream -s with 32M buffer size to get the most out of LZ4.
• If you is restricted from using 3rd party libraries or want a little bit better compression, check JDK deflate (lvl=1) CO Dec-it is able to compress the same file at ~75 Mb/sec.

(translation www.java-performance.com) improve Java program performance--JDK (iv)