i wonder why..

  • Thread starter Thread starter Imran Koradia
  • Start date Start date
I

Imran Koradia

why would one want to use a MemoryStream?
it basically creates a stream in memory to read/write data from/to memory -
which we can accomplish with our regular objects as well. We could read
strings/bytes etc from files using the FileStream (or from network using
NetworkStream) into the relevant .NET object and work on it as long as we
wish. if needed to have the data in memory for future use, we can just leave
the object hanging around as long as we want to make use of the data .
the only thing different i would think is that while objects within the
application basically stick to the address space that the OS assigns to the
process for the application, the memorysteam is free to read/write from/to
memory thats outside the application scope. is this correct? if so, are
there any performance implications if we leave a large amount of data
hanging around in the application-specific memory as opposed to writing it
somewhere else in memory and reading it back when needed (consider reading a
large text file into a stringbuilder and leaving it hanging around for the
entire application lifetime as opposed to writing it to memory using a
MemoryStream and reading it back when needed)?
just ran into thoughts while reading about .NET Stream objects..
any input/feedback is greatly appreciated.

Imran.
 
Hi Imran,

A memory stream is to replace a process that has to write and read to disk,
without the need of that disk (or an other hard media).

The memorystream exist only inside one application.

For the purpose you want to use it (inside an application), you can in my
opinion better use a whatever Array or Table. Because for that you will need
the same amount of memory, while you can access it on better ways than the
only streaming way with single memorystream.

I hope this helps?

Cor
 
why would one want to use a MemoryStream?
it basically creates a stream in memory to read/write data from/to memory -
which we can accomplish with our regular objects as well. We could read
strings/bytes etc from files using the FileStream (or from network using
NetworkStream) into the relevant .NET object and work on it as long as we
wish. if needed to have the data in memory for future use, we can just leave
the object hanging around as long as we want to make use of the data .
the only thing different i would think is that while objects within the
application basically stick to the address space that the OS assigns to the
process for the application, the memorysteam is free to read/write from/to
memory thats outside the application scope. is this correct? if so, are
there any performance implications if we leave a large amount of data
hanging around in the application-specific memory as opposed to writing it
somewhere else in memory and reading it back when needed (consider reading a
large text file into a stringbuilder and leaving it hanging around for the
entire application lifetime as opposed to writing it to memory using a
MemoryStream and reading it back when needed)?
just ran into thoughts while reading about .NET Stream objects..
any input/feedback is greatly appreciated.

Imran.
Click to expand...

One place I've been known to use MemoryStream is in cloning serializable
objects. Write the serialized object to the memorystream, and then
deserialize the object from the stream. Much faster then writing to disk
:)
 
Imran,
In addition to the other comments.
why would one want to use a MemoryStream?
Click to expand...
You would want to use a MemoryStream, when you need to use a MemoryStream.
We could read
strings/bytes etc from files using the FileStream (or from network using
NetworkStream) into the relevant .NET object and work on it as long as we
wish.
Click to expand...
A MemoryStream allows us to Write our strings/bytes to memory, then read
them later.
if needed to have the data in memory for future use, we can just leave
the object hanging around as long as we want to make use of the data . Correct!

the only thing different i would think is that while objects within the
application basically stick to the address space that the OS assigns to the
process for the application, the memorysteam is free to read/write from/to
memory thats outside the application scope. is this correct?
Click to expand...
No. The MemoryStream is in your application address space.
if so, are
there any performance implications if we leave a large amount of data
hanging around in the application-specific memory as opposed to writing it
somewhere else in memory and reading it back when needed (...)?
Click to expand...
There are always performance implications of leaving large amounts of data
hanging around in memory!
(consider reading a
large text file into a stringbuilder and leaving it hanging around for the
entire application lifetime as opposed to writing it to memory using a
MemoryStream and reading it back when needed)?
Click to expand...
I would not read a large text file into a MemoryStream, I would read it
directly into a StringBuilder, String or other specific object that I needed
it in.
just ran into thoughts while reading about .NET Stream objects..
any input/feedback is greatly appreciated.
Click to expand...
You would use a MemoryStream anyplace you needed a temporary file! Rather
then creating a temporary file on disk, you can use a MemoryStream to create
a temporary file in memory.

As Tom suggests, you can use a MemoryStream to Clone an object during
serialization.

In addition to Cloning an object, I find a MemoryStream useful in Edit
Cut/Copy/Paste & Drag & Drop implementations.

A third example: I have a project where I am doing an XslTransform using the
Stream from an HttpWebResponse and transforming it into a MemoryStream, I
then take the MemoryStream and save it as a property on a message in an
Exchange Server. Note I could have used a StringWriter instead of the
MemoryStream in this case.

Hope this helps
Jay
 
wow...that explains a lot. thanks all for the feedback. i really appreciate
that. i'll keep these pointers in mind.
 
Back
Top