• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

BufferedInputStream possibly unnecessary for FileInputStream

 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm familiar with BufferedInputStream and FileInputStream, and in general I always use them together, but if I am reading the entire file is BufferedInputStream really doing anything?

For example, compare the following two code snippets:





Since I am reading the File in a 8192 byte array in both cases, does the BufferedInputStream actually do much here or is it just adding extra overhead/memory for no reason?
 
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When reading from an input stream there is no guarantee the supplied byte array will be filled, you must check the return value which tells you how many bytes have been added to the array. When reading a local file in a tight loop there is probably little to no difference as the array will probably be filled but if the processing in the loop body takes some time and reading the bytes from the file is slow (ie over a slow network) I would think using a BufferedInputStream will improve performance.

I guess the way to find out is to read in a large file and time how long each method takes for a variety of scenarios.
 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a tight loop like this, I've never seen an example where bytesRead wouldn't always be equal to buffer.length, while the end of the file has not yet been reached. And in any case where it does not, it's not clear that a BufferedInputStream would help.

I could run tons of tests on the code above, but I'd like to make sure I understand conceptually first. That said, is there any conceptual reason that BufferedInputStream will actually make a difference here, since the way I'm reading FileInputStream is virtually identical to what a BufferedInputStream would do.

Note: For simplicity, assume the BufferedInputStream uses 8192 as the default buffer size.
 
Tony Docherty
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In a tight loop like this, I've never seen an example where bytesRead wouldn't always be equal to buffer.length, while the end of the file has not yet been reached.


When applied to reading a file on a local file system I agree. Although this may not apply to some of the old and slow CD drives etc.

And in any case where it does not, it's not clear that a BufferedInputStream would help.


In a tight loop like this and with a BufferedInputStream with the same buffer size as you are using then yes it is of no advantage and in fact it will probably just add overhead.

Where a BufferedInputStream has the advantage is when using a larger buffer size than would normally be filled by single a call to read(byte[])
Scrub that, I've just looked at the source code and basically a BufferedInputStream is just doing what you are doing by by calling read(byte[]). I had naively assumed it would pull some clever stunt like continuing to load data into the buffer on a background thread so the buffer would be re-filled ready for the next read, but it doesn't.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic