Performance on string destruction

[SevDer]

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML response.
When I am done with it, I want to clear out this field to give some relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks
--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers

[Bob Grommes]

Setting it to null will accomplish nothing unless perhaps there is a lot
of other processing in the same method before it exits. Otherwise, just
let the StringBuilder reference go out of scope when the routine exits.

Deleting what's in the buffer would only make sense if you're going to
reuse it. Setting the StringBuilder instance to null will cause the GC
to reclaim the whole object, including the buffer, *at such time as the
GC feels it's necessary*.

I emphasized the last point because so many people get bogged down in
anxiously watching memory (often looking at the wrong memory indicator,
as well) and then have a cow when it doesn't (appear to) be freed up.
In effect, memory is marked by the GC as reclaimable when it's no longer
needed.

--Bob

SevDer wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML response.
When I am done with it, I want to clear out this field to give some relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML response.
When I am done with it, I want to clear out this field to give some relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;
Well the first line in former option isn't going to do what you want it
to - it's just going to return an empty string which you then ignore.
or do you have any other suggestion?

Is this field a member variable in an object which is meant to live for
significantly longer? If so, setting it to null is the way forward.

However, I rarely find that it's a good idea to have member variables
which effectively have a lifetime which is shorter than the containing
object. Do you really need it to be a member variable? What's the
context here?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SevDer]

Hi Jon,

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).

Do you still suggest to reference it to "null"?

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML
response.
When I am done with it, I want to clear out this field to give some
relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

Well the first line in former option isn't going to do what you want it
to - it's just going to return an empty string which you then ignore.

or do you have any other suggestion?

Is this field a member variable in an object which is meant to live for
significantly longer? If so, setting it to null is the way forward.

However, I rarely find that it's a good idea to have member variables
which effectively have a lifetime which is shorter than the containing
object. Do you really need it to be a member variable? What's the
context here?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bob Grommes]

Setting it to null will accomplish nothing unless perhaps there is a lot
of other processing in the same method before it exits. Otherwise, just
let the StringBuilder reference go out of scope when the routine exits.

Deleting what's in the buffer would only make sense if you're going to
reuse it. Setting the StringBuilder instance to null will cause the GC
to reclaim the whole object, including the buffer, *at such time as the
GC feels it's necessary*.

I emphasized the last point because so many people get bogged down in
anxiously watching memory (often looking at the wrong memory indicator,
as well) and then have a cow when it doesn't (appear to) be freed up.
In effect, memory is marked by the GC as reclaimable when it's no longer
needed.

--Bob

SevDer wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML response.
When I am done with it, I want to clear out this field to give some relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks

[SevDer]

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess this
gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What is
the biggest advantage of StringBuilder against string when we do not append
any data, but just parse and grab data from it?

Thanks for your help

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:eV**************@tk2msftngp13.phx.gbl...

Setting it to null will accomplish nothing unless perhaps there is a lot
of other processing in the same method before it exits. Otherwise, just
let the StringBuilder reference go out of scope when the routine exits.

Deleting what's in the buffer would only make sense if you're going to
reuse it. Setting the StringBuilder instance to null will cause the GC to
reclaim the whole object, including the buffer, *at such time as the GC
feels it's necessary*.

I emphasized the last point because so many people get bogged down in
anxiously watching memory (often looking at the wrong memory indicator, as
well) and then have a cow when it doesn't (appear to) be freed up. In
effect, memory is marked by the GC as reclaimable when it's no longer
needed.

--Bob

SevDer wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML
response.
When I am done with it, I want to clear out this field to give some
relief to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks

[SevDer]

Hi Jon,

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).

Do you still suggest to reference it to "null"?

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML
response.
When I am done with it, I want to clear out this field to give some
relief
to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

Well the first line in former option isn't going to do what you want it
to - it's just going to return an empty string which you then ignore.

or do you have any other suggestion?

Is this field a member variable in an object which is meant to live for
significantly longer? If so, setting it to null is the way forward.

However, I rarely find that it's a good idea to have member variables
which effectively have a lifetime which is shorter than the containing
object. Do you really need it to be a member variable? What's the
context here?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SevDer]

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess this
gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What is
the biggest advantage of StringBuilder against string when we do not append
any data, but just parse and grab data from it?

Thanks for your help

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:eV**************@tk2msftngp13.phx.gbl...

Setting it to null will accomplish nothing unless perhaps there is a lot
of other processing in the same method before it exits. Otherwise, just
let the StringBuilder reference go out of scope when the routine exits.

Deleting what's in the buffer would only make sense if you're going to
reuse it. Setting the StringBuilder instance to null will cause the GC to
reclaim the whole object, including the buffer, *at such time as the GC
feels it's necessary*.

I emphasized the last point because so many people get bogged down in
anxiously watching memory (often looking at the wrong memory indicator, as
well) and then have a cow when it doesn't (appear to) be freed up. In
effect, memory is marked by the GC as reclaimable when it's no longer
needed.

--Bob

SevDer wrote:

Thinking for performance & system resources;

I have a string field inside a major object that contains big XML
response.
When I am done with it, I want to clear out this field to give some
relief to memory.

Should I use this:
SabreContractResponse.Remove(0,SabreContractRespon se.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).
That doesn't necessarily mean it has to be a member variable in that
class - there are other ways of sharing data between threads. I'd need
to know more about what you're doing to say how to go about it though.
Do you still suggest to reference it to "null"?

Only if it absolutely has to be a member variable of your long-lived
object.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).
That doesn't necessarily mean it has to be a member variable in that
class - there are other ways of sharing data between threads. I'd need
to know more about what you're doing to say how to go about it though.
Do you still suggest to reference it to "null"?

Only if it absolutely has to be a member variable of your long-lived
object.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Kevin Yu [MSFT]]

Hi SevDer,

I think setting the member to null is just fine. It will release the handle
to the string object, and leave it to GC.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi SevDer,

I think setting the member to null is just fine. It will release the handle
to the string object, and leave it to GC.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Bob Grommes]

I'm not sure I understand your question clearly, but StringBuilder is
generally used when you need to append many strings into a larger one.
If whatever operation you're doing doesn't require significant
concatenation to that data once it's obtained, then I would just put the
contents into a string in the first place.

That doesn't really impact the question of what you should do to get rid
of the resulting object when you're done with it. Whether the object is
a string or a StringBuilder the same principles apply; when you're done,
in most real world scenarios simply letting it go out of scope is fine
unless, as appears to be the case here, it is a shared object that won't
be needed for some time, in which case you could set it to null.

In the case of a StringBuilder if it's going to continue to be reused my
impulse would be to clear its buffer but not set it to null; that way
other processes don't have the slight overhead of newing up another
StringBuilder, but can simply use what's already there.

--Bob

SevDer wrote:

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess this
gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What is
the biggest advantage of StringBuilder against string when we do not append
any data, but just parse and grab data from it?

Thanks for your help

[Bob Grommes]

I'm not sure I understand your question clearly, but StringBuilder is
generally used when you need to append many strings into a larger one.
If whatever operation you're doing doesn't require significant
concatenation to that data once it's obtained, then I would just put the
contents into a string in the first place.

That doesn't really impact the question of what you should do to get rid
of the resulting object when you're done with it. Whether the object is
a string or a StringBuilder the same principles apply; when you're done,
in most real world scenarios simply letting it go out of scope is fine
unless, as appears to be the case here, it is a shared object that won't
be needed for some time, in which case you could set it to null.

In the case of a StringBuilder if it's going to continue to be reused my
impulse would be to clear its buffer but not set it to null; that way
other processes don't have the slight overhead of newing up another
StringBuilder, but can simply use what's already there.

--Bob

SevDer wrote:

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess this
gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What is
the biggest advantage of StringBuilder against string when we do not append
any data, but just parse and grab data from it?

Thanks for your help

[SevDer]

Thanks for details Bob.

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

I'm not sure I understand your question clearly, but StringBuilder is
generally used when you need to append many strings into a larger one. If
whatever operation you're doing doesn't require significant concatenation
to that data once it's obtained, then I would just put the contents into a
string in the first place.

That doesn't really impact the question of what you should do to get rid
of the resulting object when you're done with it. Whether the object is a
string or a StringBuilder the same principles apply; when you're done, in
most real world scenarios simply letting it go out of scope is fine
unless, as appears to be the case here, it is a shared object that won't
be needed for some time, in which case you could set it to null.

In the case of a StringBuilder if it's going to continue to be reused my
impulse would be to clear its buffer but not set it to null; that way
other processes don't have the slight overhead of newing up another
StringBuilder, but can simply use what's already there.

--Bob

SevDer wrote:

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess
this gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What
is the biggest advantage of StringBuilder against string when we do not
append any data, but just parse and grab data from it?

Thanks for your help

[SevDer]

Thanks for details Bob.

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

I'm not sure I understand your question clearly, but StringBuilder is
generally used when you need to append many strings into a larger one. If
whatever operation you're doing doesn't require significant concatenation
to that data once it's obtained, then I would just put the contents into a
string in the first place.

That doesn't really impact the question of what you should do to get rid
of the resulting object when you're done with it. Whether the object is a
string or a StringBuilder the same principles apply; when you're done, in
most real world scenarios simply letting it go out of scope is fine
unless, as appears to be the case here, it is a shared object that won't
be needed for some time, in which case you could set it to null.

In the case of a StringBuilder if it's going to continue to be reused my
impulse would be to clear its buffer but not set it to null; that way
other processes don't have the slight overhead of newing up another
StringBuilder, but can simply use what's already there.

--Bob

SevDer wrote:

Hi Bob,

First, there are a lot of processing in the container object. It is being
used in ASP.NET by 4-8 threads and kept in Session variable. (I guess
this gives the main idea about the container object)

For using the string builder, we get the XML from a service at once. What
is the biggest advantage of StringBuilder against string when we do not
append any data, but just parse and grab data from it?

Thanks for your help

[SevDer]

Hi Jon,

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes and
can be destructed along with that sub classes, but this is a rather old code
and I cannot make some conceptual changes to everything where I am trying to
optimize it as much as I can.

As a good example

MainSessionKeptObject
-stringfield1
-stringfield2
-many other fields/members

ThreadStarterMethod()
-> opens multiple threads

Each Thread updates their related stringfield.
======================================

When all the threads are done, I am now setting these stringfields to
"null", but I don't know if this will help in memory release.

Many thanks for all the information you provided

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most
fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).

That doesn't necessarily mean it has to be a member variable in that
class - there are other ways of sharing data between threads. I'd need
to know more about what you're doing to say how to go about it though.

Do you still suggest to reference it to "null"?

Only if it absolutely has to be a member variable of your long-lived
object.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SevDer]

Hi Jon,

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes and
can be destructed along with that sub classes, but this is a rather old code
and I cannot make some conceptual changes to everything where I am trying to
optimize it as much as I can.

As a good example

MainSessionKeptObject
-stringfield1
-stringfield2
-many other fields/members

ThreadStarterMethod()
-> opens multiple threads

Each Thread updates their related stringfield.
======================================

When all the threads are done, I am now setting these stringfields to
"null", but I don't know if this will help in memory release.

Many thanks for all the information you provided

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

The member variable lives relatively shorter than the object.
Objects lives along with the ASP.NET session, and it is the most
fundemental
object to the application.

And one important thing about that member variable is that, it is being
updated by thread(s).

That doesn't necessarily mean it has to be a member variable in that
class - there are other ways of sharing data between threads. I'd need
to know more about what you're doing to say how to go about it though.

Do you still suggest to reference it to "null"?

Only if it absolutely has to be a member variable of your long-lived
object.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes and
can be destructed along with that sub classes, but this is a rather old code
and I cannot make some conceptual changes to everything where I am trying to
optimize it as much as I can.

Ah, right. If you're stuck with that design for external reasons,
that's fair enough - just set it to null. It might be worth adding a
comment to the effect that a redesign might be a good idea.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes and
can be destructed along with that sub classes, but this is a rather old code
and I cannot make some conceptual changes to everything where I am trying to
optimize it as much as I can.

Ah, right. If you're stuck with that design for external reasons,
that's fair enough - just set it to null. It might be worth adding a
comment to the effect that a redesign might be a good idea.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SevDer]

Thanks Jon.

But 1 final question: Will this help me to save some memory? I really have
doubts about that.

Thanks again.

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory
consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes
and
can be destructed along with that sub classes, but this is a rather old
code
and I cannot make some conceptual changes to everything where I am trying
to
optimize it as much as I can.

Ah, right. If you're stuck with that design for external reasons,
that's fair enough - just set it to null. It might be worth adding a
comment to the effect that a redesign might be a good idea.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SevDer]

Thanks Jon.

But 1 final question: Will this help me to save some memory? I really have
doubts about that.

Thanks again.

--

SevDer
http://www.sevder.com
A new .NET Source For .NET Developers
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

SevDer <se****@newsgroup.nospam> wrote:

What I basically do is, checking some 3rd party information from multiple
sources where all have different responses and store these responses in
string field for parsing and when I am done, I want to clear them out to
save from memory. The containing object lives as long as the session and
kept in session which basically generates one of the most memory
consuming
things (I guess).
Note: For sure these responses does not have to be in the main containing
class and can be kept in individual source response processing classes
and
can be destructed along with that sub classes, but this is a rather old
code
and I cannot make some conceptual changes to everything where I am trying
to
optimize it as much as I can.

Ah, right. If you're stuck with that design for external reasons,
that's fair enough - just set it to null. It might be worth adding a
comment to the effect that a redesign might be a good idea.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

But 1 final question: Will this help me to save some memory? I really have
doubts about that.

It will mean the string can be garbage collected, which it wouldn't be
able to otherwise.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

But 1 final question: Will this help me to save some memory? I really have
doubts about that.

It will mean the string can be garbage collected, which it wouldn't be
able to otherwise.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too