difference between memory stream and filestream

The other answers here are great, but I thought one that takes a really high level look at what purpose steams serve might be useful. There's a bit of simplification going on in the explanation below, but hopefully this gets the idea across:

What is a stream?

A stream is effectively the flow of data between two places, it's the pipe rather than the contents of that pipe.

A bad analogy to start

Imagine a water desalination plant (something that takes seawater, removes the salt and outputs clean drinking water to the water network):

The desalination plant can't remove the salt from all of the sea at one time (and nor would we want it to… where would the saltwater fish live?), so instead we have:

• A SeaStream that sucks a set amount of water at a time into the plant.
• That SeaStream is connected to the DesalinationStream to remove the salt
• And the output of the DesalinationStream is connected to the DrinkingWaterNetworkStream to output the now saltless water to the drinking water supply.

OK, so what's that got to do with computers?

Moving big files all at once can be problematic

Frequently in computing we want to move data between two locations, e.g. from an external hard drive to a binary field in a database (to use the example given in another answer). We can do that by copying all of the data from the file from location A into the computer's memory and from there to to Location B, but if the file is large or the source or destination are potentially unreliable then moving the whole file at once may be either unfeasible or unwise.

For example, say we want to move a large file on a USB stick to a field in a database. We could use a 'System.IO.File' object to retrieve that whole file into the computer's memory and then use a database connection to pass that file onto the database.

But, that's potentially problematic, what if the file is larger than the computer's available RAM? Now the file will potentially be cached to the hard drive, which is slow, and it might even slow the computer down too.

Likewise, what if the data source is unreliable, e.g. copying a file from a network drive with a slow and flaky WiFi connection? Trying to copy a large file in one go can be infuriating because you get half the file and then the connection drops out and you have to start all over again, only for it to potentially fail again.

It can be better to split the file and move it a piece at a time

So, rather than getting whole file at once, it would be better to retrieve the file a piece at a time and pass each piece on to the destination one at a time. This is what a Stream does and that's where the two different types of stream you mentioned come in:

• We can use a FileStream to retrieve data from a file a piece at a time
• and the database API may make available a MemoryStream endpoint we can write to a piece at a time.
• We connect those two 'pipes' together to flow the file pieces from file to database.

Even if the file wasn't too big to be held in RAM, without streams we were still doing a number or read/write operations that we didn't need to. The stages we we're carrying out were:

1. Retrieving the data from the disk (slow)
2. Writing to a File object in the computer's memory (a bit faster)
3. Reading from that File object in the computer's memory (faster again)
4. Writing to the database (probably slow as there's probably a spinning disk hard-drive at the end of that pipe)

Streams allow us to conceptually do away with the middle two stages, instead of dragging the whole file into computer memory at once, we take the output of the operation to retrieve the data and pipe that straight to the operation to pass the data onto the database.

Other benefits of streams

Separating the retrieval of the data from the writing of the data like this also allows us to perform actions between retrieving the data and passing it on. For example, we could add an encryption stage, or we could write the incoming data to more than one type of output stream (e.g. to a FileStream and a NetworkStream).

Streams also allow us to write code where we can resume the operation should the transfer fail part way through. By keeping track of the number of pieces we've moved, if the transfer fails (e.g. if the network connection drops out) we can restart the Stream from the point at which we received the last piece (this is the offset in the BeginRead method).

Stream is a representation of bytes. Both these classes derive from the Stream class which is abstract by definition.

As the name suggests, a FileStream reads and writes to a file whereas a MemoryStream reads and writes to the memory. So it relates to where the stream is stored.

Now it depends how you plan to use both of these. For eg: Let us assume you want to read binary data from the database, you would go in for a MemoryStream. However if you want to read a file on your system, you would go in for a FileStream.

One quick advantage of a MemoryStream is that there is not need to create temporary buffers and files in an application.

While a file stream reads from a file, a memory stream can be used to read data mapped in the computer's internal memory (RAM). You are basically reading/writing streams of bytes from memory.

In simplest form, a MemoryStream writes data to memory, while a FileStream writes data to a file.

Typically, I use a MemoryStream if I need a stream, but I don't want anything to hit the disk, and I use a FileStream when writing a file to disk.