<< Optimal Buffer and Destination Byte Array Size for java.io.BufferedInputStream Reads (for a fast disk) | Home | Adobe AIR MIME type for Apache Tomcat 6 >>

Optimal Buffer and Destination Byte Array Size for java.io.BufferedInputStream Reads (for a slow disk)

A continuation of micro benchmarking
Bookmark and Share

Earlier in the week I ran some micro-benchmarks against my new very performant Intel X25M solid state drive. Today, for 'kicks', I ran the same benchmarks with the same data against a 5,400 RPM external USB-attached 3.5" hard disk drive. Wow, what a difference that makes!

Destination Byte Array Size vs. KBps (for 16 different Buffer Sizes + the default)

Destination Byte Array Size vs. KBps by BufferedInputStream Buffer Size
(Larger Image)

Detailed description of the graph (same as previous post):

  • x-axis: The destination byte array size used in individual read method calls as defined by payloadSize in this snippet:
        byte[] payload = new byte[payloadSize];
    int readIn = is.read(payload);
  • y-axis: The speed in Kilobytes per second for a complete build up, file opening and reading, and the algorithm's computation.
  • series (individual lines): Individual BufferedInputStream buffer size's as set with buffSize during class initialization.
        FileInputStream fis = FileInputStream(file);
    InputStream is = new BufferedInputStream(fis, buffSize)

For a slower disk, the conclusions are different only in the specific sizes:

  • One generally cannot go wrong with a destination byte array size of 128 bytes, regardless of what the BufferedInputStream's buffer size has been initialized to. (As opposed to 512KB to 1024KB for the SSD.)
  • BufferedInputStream's default buffer size is pretty well tuned, as long as one has a destination byte array size 2 bytes in size, or larger. (In contrast with 8 or 16 bytes for the SSD tests.)
  • There is no point in having BufferedInputStream's default buffer size initialized to anything larger than 128 Bytes (1KB for the SSD). In fact, if an application is going to have many concurrent threads running this code (like in a web application) then large values will only wastefully consume memory, limiting overall scalability.
  • The lower destination byte array sizes seem to have some sort of Sigmoid Function. (Same as SSD.)
  • My new SSD is freaky fast. ~130,000KBps is ~125MBps! Yeah, baby!

    • One aspect of this entire performance question that I have not measured is the CPU load for these different operations. Hmmm...maybe for a new post...

    Tags :
    Add a comment RSS feed for responses to this blog entry
    Posted by Stu Thompson on 31 December 2009 17:21:00 CET #



    Add a comment Send a TrackBack