MemoryStream.WriteTo（Stream destinationStream）与Stream.CopyTo（Stream destinationStream）

Question

Which one is better : MemoryStream.WriteTo(Stream destinationStream) or Stream.CopyTo(Stream destinationStream) ??

I am talking about the comparison of these two methods without Buffer as I am doing like this :

Stream str = File.Open("SomeFile.file");
MemoryStream mstr = new MemoryStream(File.ReadAllBytes("SomeFile.file"));

using(var Ms = File.Create("NewFile.file", 8 * 1024))
{
    str.CopyTo(Ms) or mstr.WriteTo(Ms);// Which one will be better??
}

Update

Here is what I want to Do :

• Open File [ Say "X" Type File]
• Parse the Contents
• From here I get a Bunch of new Streams [ 3 ~ 4 Files ]
• Parse One Stream
• Extract Thousands of files [ The Stream is an Image File ]
• Save the Other Streams To Files
• Editing all the Files
• Generate a New "X" Type File.

I have written every bit of code which is actually working correctly..

But Now I am optimizing the code to make the most efficient.

Answer 1

It is an historical accident that there are two ways to do the same thing. MemoryStream always had the WriteTo() method, Stream didn't acquire the CopyTo() method until .NET 4.

The MemoryStream.WriteTo() version looks like this:

public virtual void WriteTo(Stream stream)
{
    // Exception throwing code elided...
    stream.Write(this._buffer, this._origin, this._length - this._origin);
}

The Stream.CopyTo() implementation like this:

private void InternalCopyTo(Stream destination, int bufferSize)
{
    int num;
    byte[] buffer = new byte[bufferSize];
    while ((num = this.Read(buffer, 0, buffer.Length)) != 0)
    {
        destination.Write(buffer, 0, num);
    }
}

Stream.CopyTo() is more universal, it works for any stream. And helps programmers that fumble copying data from, say, a NetworkStream. Forgetting to pay attention to the return value from Read() was a very common bug. But it of course copies the bytes twice and allocates that temporary buffer , MemoryStream doesn't need it since it can write directly from its own buffer. So you'd still prefer WriteTo(). Noticing the difference isn't very likely.

Answer 2

MemoryStream.WriteTo : Writes the entire contents of this memory stream to another stream.

Stream.CopyTo : Reads the bytes from the current stream and writes them to the destination stream. Copying begins at the current position in the current stream. You'll need to seek back to 0, to get the whole source stream copied.

So I think MemoryStream.WriteTo better option for this situation

Answer 3

If you use Stream.CopyTo , you don't need to read all the bytes into memory to start with. However:

• This code would be simpler if you just used File.Copy

• If you are going to load all the data into memory, you can just use:

   byte[] data = File.ReadAllBytes("input"); File.WriteAllBytes("output", data); 

• You should have a using statement for the input as well as the output stream

If you really need processing so can't use File.Copy , using Stream.CopyTo will cope with larger files than loading everything into memory. You may not need that, of course, or you may need to load the whole file into memory for other reasons.

If you have got a MemoryStream , I'd probably use MemoryStream.WriteTo rather than Stream.CopyTo , but it probably won't make much difference which you use, except that you need to make sure you're at the start of the stream when using CopyTo .

Answer 4

I think Hans Passant's claim of a bug in MemoryStream.WriteTo() is wrong; it does not "ignore the return value of Write()". Stream.Write() returns void, which implies to me that the entire count bytes are written, which implies that Stream.Write() will block as necessary to complete the operation to, eg, a NetworkStream, or throw if it ultimately fails.

That is indeed different from the write() system call in ?nix, and its many emulations in libc and so forth, which can return a "short write". I suspect Hans leaped to the conclusion that Stream.Write() followed that, which I would have expected, too, but apparently it does not.

It is conceivable that Stream.Write() could perform a "short write", without returning any indication of that, requiring the caller to check that the Position property of the Stream has actually been advanced by count. That would be a very error-prone API, and I doubt that it does that, but I have not thoroughly tested it. (Testing it would be a bit tricky: I think you would need to hook up a TCP NetworkStream with a reader on the other end that blocked forever, and write enough to fill up the wire buffers. Or something like that...)

The comments for Stream.Write() are not quite unambiguous:

Summary: When overridden in a derived class, writes a sequence of bytes to the current stream and advances the current position within this stream by the number of bytes written. Parameters: buffer: An array of bytes. This method copies count bytes from buffer to the current stream.

Compare that to the Linux man page for write(2):

write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd.

Note the crucial "up to". That sentence is followed by explanation of some of the conditions under which a "short write" might occur, making it very explicit that it can occur.

This is really a critical issue: we need to know how Stream.Write() behaves, beyond all doubt.

Answer 5

The CopyTo method creates a buffer, populates its with data from the original stream and then calls the Write method passing the created buffer as a parameter. The WriteTo uses the memoryStream's internal buffer to write. That is the difference. What is better - it is up to you to decide which method you prefer.

Answer 6

Creating a MemoryStream from a HttpInputStream in Vb.Net:

Dim filename As String = MyFile.PostedFile.FileName
Dim fileData As Byte() = Nothing
Using binaryReader = New BinaryReader(MyFile.PostedFile.InputStream)
    binaryReader.BaseStream.Position = 0
    fileData = binaryReader.ReadBytes(MyFile.PostedFile.ContentLength)
End Using
Dim memoryStream As MemoryStream = New MemoryStream(fileData)