Performance on string destruction

  • Thread starter Thread starter SevDer
  • Start date Start date
S

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,SabreContractResponse.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;

or do you have any other suggestion?

Thanks
 
SevDer said:
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,SabreContractResponse.Length);
SabreContractResponse = null;

or just this:
SabreContractResponse = null;
Click to expand...

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?
Click to expand...

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?
 
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
 
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
 
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 said:
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).
Click to expand...

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"?
Click to expand...

Only if it absolutely has to be a member variable of your long-lived
object.
 
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."
 
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
 
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
 
SevDer said:
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.
Click to expand...

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.
 
SevDer said:
But 1 final question: Will this help me to save some memory? I really have
doubts about that.
Click to expand...

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