5

I was searching for a BinaryReader.Skip function, while I came across this feature request on msdn. He said you can provide your own BinaryReader.Skip() function, by using this.

Only looking at this code, I'm wondering why he chose this way to skip a certain amount of bytes:

    for (int i = 0, i < count; i++) {
        reader.ReadByte();
    }

Is there a difference between that and:

reader.ReadBytes(count);

Even if it's just a small optimalisation, I'd like to undestand. Because now it doesnt make sense to me why you would use the for loop.

public void Skip(this BinaryReader reader, int count) {
    if (reader.BaseStream.CanSeek) { 
        reader.BaseStream.Seek(count, SeekOffset.Current); 
    }
    else {
        for (int i = 0, i < count; i++) {
            reader.ReadByte();
        }
    }
}

4 Answers 4

2

No, there is no difference. EDIT: Assuming that the stream has enough byes

The ReadByte method simply forwards to the underlying Stream's ReadByte method.

The ReadBytes method calls the underlying stream's Read until it reads the required number of bytes.
It's defined like this:

public virtual byte[] ReadBytes(int count) {
    if (count < 0) throw new ArgumentOutOfRangeException("count", Environment.GetResourceString("ArgumentOutOfRange_NeedNonNegNum")); 
    Contract.Ensures(Contract.Result<byte[]>() != null); 
    Contract.Ensures(Contract.Result<byte[]>().Length <= Contract.OldValue(count));
    Contract.EndContractBlock(); 
    if (m_stream==null) __Error.FileNotOpen();

    byte[] result = new byte[count];

    int numRead = 0;
    do { 
        int n = m_stream.Read(result, numRead, count); 
        if (n == 0)
            break; 
        numRead += n;
        count -= n;
    } while (count > 0);

    if (numRead != result.Length) {
        // Trim array.  This should happen on EOF & possibly net streams. 
        byte[] copy = new byte[numRead]; 
        Buffer.InternalBlockCopy(result, 0, copy, 0, numRead);
        result = copy; 
    }

    return result;
} 

For most streams, ReadBytes will probably be faster.

Sign up to request clarification or add additional context in comments.

5 Comments

That doesn't make any sense to me though. Why would ReadBytes be faster?
@Timo, if the number of bytes is large enough, you'll get a block memory copy and fewer total method calls. ReadByte is virtual, which can add a small amount of overhead. It's not likely to be a huge difference either way.
@Dan, @Timo: It will issue fewer requests to the underlying stream. When reading from disk, that can make a difference.
Okay thanks a lot! By the way where did you get that definition?
@SLaks, Most I/O-bound stream implementations have some internal buffering, so I wouldn't expect much impact from reading single bytes vs. medium-sized chunks. I haven't profiled it, though, so I'm honestly not sure.
2

ReadByte will throw an EndOfStreamException if the end of the stream is reached, whereas ReadBytes will not. It depends on whether you want Skip to throw if it cannot skip the requested number of bytes without reaching the end of the stream.

Comments

1

ReadBytes is faster than multiple ReadByte calls.

Comments

0

Its a very small optimization which will occasionally skip bytes (rather then reading them into ReadByte) Think of it this way

if(vowel)
{
    println(vowel);
}
else
{
nextLetter();
}

If you can prevent that extra function call you save a little runtime

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.