i wonder why..

[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.

[Cor Ligthert]

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.

[Tom Shelton]

On Sun, 27 Jun 2004 19:18:55 -0400, Imran Koradia wrote:

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.

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
:)

--
Tom Shelton [MVP]

[Jay B. Harlow [MVP - Outlook]]

Imran,
In addition to the other comments.

why would one want to use a MemoryStream? 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. 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? 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 (...)? 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)? 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. 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
"Imran Koradia" <no****@microsoft.com> wrote in message
news:eF***************@TK2MSFTNGP10.phx.gbl... 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.

[Imran Koradia]

wow...that explains a lot. thanks all for the feedback. i really appreciate
that. i'll keep these pointers in mind.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uN**************@tk2msftngp13.phx.gbl...

Imran,
In addition to the other comments.

why would one want to use a MemoryStream? 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.

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?

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 (...)?

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)?

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. 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
"Imran Koradia" <no****@microsoft.com> wrote in message
news:eF***************@TK2MSFTNGP10.phx.gbl...

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.