FileStream.ReadByte - Inefficient - What is the meaning of this?

Question

The default implementation on Stream creates a new single-byte array and then calls Read. While this is formally correct, it is inefficient. Any stream with an internal buffer should override this method and provide a much more efficient version that reads the buffer directly, avoiding the extra array allocation on every call.

Taken from the FileStream.ReadByte documentation:

http://msdn.microsoft.com/en-us/library/system.io.filestream.readbyte.aspx

What is the meaing of this and how do I overcome this inefficiency?

Answer 1

You need to use Read method to read to a buffer. Reading single byte is not efficient. Using buffer:

  byte[] buffer = new byte[4096]; // 4K
  int bytesRead =0;
  while((bytesRead = stream.Read(buffer, 0, buffer.Length))>0)
  {
  // Do whatever with buffer
  }

Answer 2

I would read that as a very poorly written way to say "don't use the ReadByte() and use Read() instead". Particularly since the documentation for Read() says

This method overrides Read.

in the Remarks section.

Answer 3

Well, the meaning seems reasonably clear - and the workaround is simply not to call ReadByte.

Don't read one byte at a time - read into a buffer of an appropriate size (I usually go for about 8K, but anything of around that order of magnitude should be fine) using the Read(byte[], int, int) method. If you need to read bytes individually after that, read them one at a time from the buffer.

This becomes a problem if you need to make sure you don't read more than you're meant to, if you see what I mean - if you're not meant to read past the first 0 byte, for example, because that means it's the start of the next "message" and you want to be able to read again later. Ideally, avoid designing yourself into that sort of situation.

Wrapping a FileStream in a BufferedStream may help in that case, but I would measure the performance carefully if it's important... and still try to avoid designs which require reading a single byte at a time if you can help it.

Answer 4

This is only of concern when you inherit from Stream. When doing so, you must provide at least a Read method, ReadByte is implemented on top of it in the base class. This is fine, but inefficient when your stream is capable of getting individual bytes directly - the default implementation would then first create a single-byte buffer internally, pass it to ReadByte to fill it, and then return the single byte. If you can implement your buffer so that the single byte can be returned directly, without allocating a temporary buffer, you should do so.

For the calling code, the only consideration is that when you need to read bytes just to store them in a buffer, Read is often more efficient than ReadByte, even when you're only reading a single byte - but if you really only need one byte, and the stream implementation you're using provides an optimized version, ReadByte may actually be faster. If you read individual bytes for immediate processing, ReadByte shouldn't be a problem at all - after all, most of the standard stream classes are buffered already and should provide an optimized ReadByte. If in doubt, profile.