6

When I am using FileInputStream to read an object (say a few bytes), does the underlying operation involve:

1) Reading a whole block of disk so that if I subsequently do another read operation, it wouldnt require a real disk read as that portion of the file was already fetched in the last read operation?

OR

2) A new disk access to take place because FileInputStream does not do any buffering and bufferedInputStream should have been used instead to achieve the effect of (1)?

I think that since the FileInputStream uses the read system call and it reads only a set of pages from hard disk, some buffering must be take place.

x4u
  • 13,877
  • 6
  • 48
  • 58
AnkurVj
  • 7,958
  • 10
  • 43
  • 55
  • 1
    I don't know the underlying OS IO sufficiently to answer, but buffering is not the only reason to avoid multiple calls. Each read operation also involves a call to a native method, which has some overhead. Reducing the number of native method calls is thus also useful. – JB Nizet Sep 14 '11 at 18:22
  • Try a simple benchmark. you probably notice an improvement. – Lynch Sep 14 '11 at 18:32

3 Answers3

7

FileInputStream will make an underlying native system call. Most OSes will do their own buffering for this. So it does not need a real disk seek for each byte. But still, you have the cost of making the native OS call, which is expensive. So BufferedStream would be preferable. However, for reading small amounts of data (like you say, a few bytes or even kBs), either one should be fine as the number of OS calls won't be that different.

Hari Menon
  • 33,649
  • 14
  • 85
  • 108
5

Native code for FileInputStream is here: it doesn't look like there is any buffering going on in there. The OS buffering may kick in, but there's no explicit indicator one way or another if/when that happens.

Femi
  • 64,273
  • 8
  • 118
  • 148
  • Thx for the coder reference. It seems like L65 and L70 are relevant. Do you know where readSingle() is implemented. It is not a system call. – Heinrich Hartmann Oct 23 '14 at 19:47
1

One thing to look out for is reading from a mounted network volume over a slow connection. I ran into a big performance issue using a non-buffered FileInputStream for this. Didn't catch it in development, because the file system was local.

Sam Barnum
  • 10,559
  • 3
  • 54
  • 60