Revisiting an old friend: Set oRS = Nothing

[Dave Anderson]

Last September, some of us engaged in a discussion of freeing resources in
ASP scripts written in JScript. It can be seen here:
http://tinyurl.com/2flzt

I recently read Eric Lippert's article on the use of *Nothing* assignments
in VB (http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx)
right before going out of scope, and was shocked by what he had to say, and
I must say it has me curious about the implications for ASP, whether written
in JScript or VBScript.

Like Lippert, I have seen a lot of documentation/advice that suggests a need
for such assignments, but little empirical evidence that it matters. I do
not mean to suggest that *Nothing* assignments are NEVER required, I simply
wonder if anyone has bothered to check if it still matters with recent
generations of IIS and such common tools as ADO or CDO.

Comments?



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Aaron Bertrand - MVP]

Is the motivation behind this type of exploration the ability to save < 20
keystrokes?

While garbage collection is supposedly a good thing, I still make it a habit
that I always use obj.close: set obj = nothing. Why leave anything to
chance? I've seen cases where adding set obj = nothing suddenly eliminated
Unspecified Error problems with Access, among other things.

It takes far longer to even think about this issue than it will ever take to
simply continue following the best practices I always have, and my coding is
always consistent... if nothing else, it's one less thing I have to check if
I'm having a problem with a page...

 

[Bob Barrows [MVP]]

Last September, some of us engaged in a discussion of freeing
resources in ASP scripts written in JScript. It can be seen here:
http://tinyurl.com/2flzt

I recently read Eric Lippert's article on the use of *Nothing*
assignments in VB
(http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx)
right before going out of scope, and was shocked by what he had to
say, and I must say it has me curious about the implications for ASP,
whether written in JScript or VBScript.

Like Lippert, I have seen a lot of documentation/advice that suggests
a need for such assignments, but little empirical evidence that it
matters. I do not mean to suggest that *Nothing* assignments are
NEVER required, I simply wonder if anyone has bothered to check if it
still matters with recent generations of IIS and such common tools as
ADO or CDO.

Comments?

I don't understand your point. The consensus of most of the people on that
page is that ADO objects should be explicitly destroyed, especially in ASP.
The comments about bugs caused by failure to explicitly destroy ADO and DAO
objects should not be taken lightly.

In the many years that I have been coding, the documentation for every
version of VB/VBA that I have used has ALWAYS said: objects are destroyed
when they go out of scope. Nevertheless, we came across memory leaks, bugs,
etc, which were resolved by explicitly destroying the objects in question.
This has always suggested to me that the documentation has always been
wrong: there are circumstances where the auto-cleanup failed, which lead to
many authors adding the "if you open it, close it; if you create it, destroy
it" mantra to their "best practices" lists. It was not makework. There are
many documented failures caused by non-adherence to this principle. Several
of those failures are mentioned in your cited blog.

For me, it's easier to remember to destroy all objects, than to remember to
destroy just my ADO objects.

Bob Barrows

 

[Dave Anderson]

Is the motivation behind this type of exploration the ability to save
< 20 keystrokes?

No. The motivation is to understand.

Many of us are relied upon to share our knowledge, either in fora such as
this, in classroom settings, or merely in discussion with our peers. I take
very seriously requests for my input, and have a distaste for repackaging
*common knowledge* as fact.

While garbage collection is supposedly a good thing, I still make it
a habit that I always use obj.close: set obj = nothing. Why leave
anything to chance?

By this reasoning, you should practice every religion that promises an
afterlife to its followers. Why leave your eternal fate to chance when you
can do something proactive about it?

I've seen cases where adding set obj = nothing suddenly eliminated
Unspecified Error problems with Access, among other things.

....which I do not challenge. Virtually every one of us has had to work with
poorly written components -- sometimes from Microsoft, sometimes from
vendors (but NEVER ones we wrote ourselves). And early versions of IIS
and/or VBScript may have been more sesitive to such problems. But what about
now? And what about the modern versions of ADO and CDO?

It takes far longer to even think about this issue than it will ever
take to simply continue following the best practices I always have,
and my coding is always consistent... if nothing else, it's one less
thing I have to check if I'm having a problem with a page...

Hey - I'm as much of a belt-AND-suspenders guy as the next. I just don't
believe in using them to keep my shoes on. Unless my shoes are the kind that
need them, that is.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Aaron Bertrand - MVP]

By this reasoning, you should practice every religion that promises an

afterlife to its followers. Why leave your eternal fate to chance when you
can do something proactive about it?

There is a big difference. The afterlife is not a proven fact, and depends
quite a bit on faith (not only a specific religion, but also the broader
sense of faith in any religion). Memory leaks are something you yourself
state that we have all seen, and we know that in at least some of these
cases, proper cleanup resolves the issue.

But what about now?

I will concede that newer versions of IIS are more likely to avoid these
problems. But I will not try and state with any certainty that they can't
still happen. I also do not recommend writing code that is supposed to run
on any IIS machine, with the presumption that will only run on version x.
You never know when your hardware will fail and suddenly the only candidate
for quick replacement is x-1. Or when you upgrade to x+1 that the behavior
is different.

A

 

[Dave Anderson]

There is a big difference. The afterlife is not a proven fact, and
depends quite a bit on faith (not only a specific religion, but also
the broader sense of faith in any religion). Memory leaks are
something you yourself state that we have all seen, and we know that
in at least some of these cases, proper cleanup resolves the issue.

Fair enough. Perhaps a better analogy would be carrying along spare tire
tubes for your car because your old car (or your grandfather's car) needed
them. At some point, you no longer need them, and they are just extra
weight, not to mention worthless advice.

Of course, I also wonder when gas stations in the USA will stop selling
"unleaded" gas. Or when my company will stop buying computers with floppy
drives.

I will concede that newer versions of IIS are more likely to avoid
these problems. But I will not try and state with any certainty that
they can't still happen.

This is what I was trying to get at. I don't know of a resource that has
used empirical evidence to show one outcome or the other. What was once good
advice may just be wasted breath today.

And as Lippert specifically addressed *Nothing* assignment just prior to end
of scope, I wonder if the problem has truly been resolved for ALL
components, not just the standard ones. If my object creation/assignment
takes place in a MySub, will the following alleviate the need to unassign
it?

On Error Resume Next
Call MySub()
On Error Goto 0

Assuming everything Lippert writes about VB applies to VBScript, it may.

I also do not recommend writing code that is supposed to run on any
IIS machine, with the presumption that will only run on version x.
You never know when your hardware will fail and suddenly the only
candidate for quick replacement is x-1.

Then I guess you don't use RegExp or Class objects. Who knows if you'll have
to go back to IIS 4.

Or when you upgrade to x+1 that the behavior is different.

I can't speculate on what is a reasonable forward compatibility expectation.
Are you saying I should prepare for the need to manage resources in [VB.NET
x+1]? To argue your point ad infinitum, assuming the possibility of a change
to designed behavior leaves open changes to anything and everything. In such
a case, the only safe code is none at all.

I would argue that any behavioral change when upgrading to x+1 is either (a)
the result of oversight by the authors of version x+1, or (b) because your
original code exploited a side effect rather than a designed behavior.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Chris Hohmann]

Last September, some of us engaged in a discussion of freeing resources in
ASP scripts written in JScript. It can be seen here:
http://tinyurl.com/2flzt

I recently read Eric Lippert's article on the use of *Nothing* assignments
in VB (http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx)
right before going out of scope, and was shocked by what he had to say, and
I must say it has me curious about the implications for ASP, whether written
in JScript or VBScript.

Like Lippert, I have seen a lot of documentation/advice that suggests a need
for such assignments, but little empirical evidence that it matters. I do
not mean to suggest that *Nothing* assignments are NEVER required, I simply
wonder if anyone has bothered to check if it still matters with recent
generations of IIS and such common tools as ADO or CDO.

Comments?

I remember the discussion well. When we left off, I had offered this
scenario:

rs.Close();
rs = null; //Marks the recordset for garbage collection
str = "This is a 64K length string..."; //Triggers garbage collection
Response.Write("Hooray. RS is dead.");

The above is based on my interpretation of this article, which you cited
during the course of our conversation:
http://rtfm.atrax.co.uk/infinitemonkeys/articles/asp/917.asp

As for empirical evidence, it should be fairly simple to compare the above
to code sans dereferencing. I look forward to hearing about your findings.

-Chris Hohmann

 

[Aaron Bertrand [MVP]]

What was once good advice may just be wasted breath today.

Why? Do you know of a NEGATIVE side effect of always setting objects to
nothing?

 

[Dave Anderson]

Why? Do you know of a NEGATIVE side effect of always setting objects
to nothing?

Would the effects need to be NEGATIVE for the advice to be worthless?

By the above reasoning reasoning, I could start telling people to set
integers to zero before scope loss, and since doing so creates no negative
side effects, there is no folly in giving such advice.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

I remember the discussion well. When we left off, I had offered this
scenario:

rs.Close();

....which I agree is necessary...

rs = null; //Marks the recordset for garbage collection

....which I assert does nothing to aid GC.

str = "This is a 64K length string..."; //Triggers garbage collection

This simply does not trigger GC. At best, new String("This is...") *might*
trigger GC, depending on the number of objects flagged. But it strains
credibility to suggest that the above triggers GC.

The above is based on my interpretation of this article, which you
cited during the course of our conversation:
http://rtfm.atrax.co.uk/infinitemonkeys/articles/asp/917.asp

Let's put my "citation" in context:

"...I am applying "mischaracterization" to...the KB article that claims
to "Destroy and de-reference" an object, third party ASP articles (ex:
http://rtfm.atrax.co.uk/infinitemonkeys/articles/asp/917.asp) in which
solutions look like VBScript solutions bent into JScript..."

I was clearly QUESTIONING the validity of that advice, not citing it as a
model of correctness.
http://tinyurl.com/2d8n7

As for empirical evidence, it should be fairly simple to compare the
above to code sans dereferencing. I look forward to hearing about
your findings.

It would be simple if I could find evidence of a memory leak. As our
intranet is built on ASP/JScript code that DOES NOT "dereference" objects, I
would think we would have noticed a memory leak by now.

How do you propose I determine the success or failure?



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

Do you know of a NEGATIVE side effect of always setting objects
to nothing?

Actually, I do.

We work with a vendor application that allows backend customization via
exposure to the VBScript engine, but which limits the overall script
lengths**. On several occasions, we have bumped against those limits, and
had to streamline our code. In some cases, the developers have shortened
variable names. In others, more drastic restructuring has been required. In
the most extreme cases, functionality has simply been capped. Nothing
assignments have never been jettisoned to date. That may change.

You can experience this yourself by creating SQL Server job step of type
"ActiveX Script" in Enterprise Manager. Fortunately, SQL Server allows you
to overcome the script length limitation by running a .js or .vbs file. But
our vendor app does not.



**We use this to integrate the product with our mainframe.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Aaron Bertrand - MVP]

It would be simple if I could find evidence of a memory leak. As our

intranet is built on ASP/JScript code that DOES NOT "dereference" objects, I
would think we would have noticed a memory leak by now.

That's one environment. So I may agree that, since you have avoided the
"worthless" advice and it has not turned out to have adverse effects, then
it is certainly fine for you to continue doing so. However, in general
recommendations for the majority of the newsgroups, e.g. people who have
myriad environments and possibly few resources to test potential memory leak
problems, I still don't feel that the advice is worthless. If it saves one
person from having a memory leak issue that they can't track down (and it
has happened to many people, just search Google), then to me that is not
worthless.

If 14 characters really makes or breaks your "code size limitation" problem,
I'd say you are developing code which is too close to the edge already, and
that it is merely convenient that you find this statement unnecessary. I
think you are considering this issue from a much more selfish perspective
than the rest of us. Which isn't a bad thing, necessarily, but you're
planning to generalize, and deem "worthless," advice -- based solely on your
environment and observations. I don't think it would be fair for the rest
of us to start telling people "don't bother setting objects to nothing."

I still think it's a good practice because there are still 3rd party COM
objects out there, being written by who knows who... better safe than sorry,
and all that. And while you're there, might as well code consistently, even
for those statements that you allegedly "know" are "worthless."

A

 

[Aaron Bertrand - MVP]

It would be simple if I could find evidence of a memory leak. As our

intranet is built on ASP/JScript code that DOES NOT "dereference" objects, I
would think we would have noticed a memory leak by now.

That's one environment. So I may agree that, since you have avoided the
"worthless" advice and it has not turned out to have adverse effects, then
it is certainly fine for you to continue doing so. However, in general
recommendations for the majority of the newsgroups, e.g. people who have
myriad environments and possibly few resources to test potential memory leak
problems, I still don't feel that the advice is worthless. If it saves one
person from having a memory leak issue that they can't track down (and it
has happened to many people, just search Google), then to me that is not
worthless.

If 14 characters really makes or breaks your "code size limitation" problem,
I'd say you are developing code which is too close to the edge already, and
that it is merely convenient that you find this statement unnecessary. I
think you are considering this issue from a much more selfish perspective
than the rest of us. Which isn't a bad thing, necessarily, but you're
planning to generalize, and deem "worthless," advice -- based solely on your
environment and observations. I don't think it would be fair for the rest
of us to start telling people "don't bother setting objects to nothing."

I still think it's a good practice because there are still 3rd party COM
objects out there, being written by who knows who... better safe than sorry,
and all that. And while you're there, might as well code consistently, even
for those statements that you allegedly "know" are "worthless."

A

 

[Aaron Bertrand - MVP]

Another point I forgot to mention is that in IIS 5.0 and up, an object is
released as soon as you dereference it (in IIS 4 and lower, release was
keyed to the page, not the code).

You're suggesting to not set = nothing, so the object isn't released until
the page goes out of scope. Depending on the content of the rest of the
page, you might be keeping those resources allocated a lot longer than they
have to be.

A

 

[Chris Hohmann]

...which I agree is necessary...



...which I assert does nothing to aid GC.

I guess that's where we'll have to agreed to disagree. By your above
reasoning then, there is no way to indicate that an object is no longer
needed and should be included in the next GC sweep.

This simply does not trigger GC. At best, new String("This is...") *might*
trigger GC, depending on the number of objects flagged. But it strains
credibility to suggest that the above triggers GC.

Maybe "triggers was a poor word choice. How about this then, the above
statement causes the GC to set a flag that says collect soon.

Let's put my "citation" in context:

"...I am applying "mischaracterization" to...the KB article that claims
to "Destroy and de-reference" an object, third party ASP articles (ex:
http://rtfm.atrax.co.uk/infinitemonkeys/articles/asp/917.asp) in which
solutions look like VBScript solutions bent into JScript..."

I was clearly QUESTIONING the validity of that advice, not citing it as a
model of correctness.
http://tinyurl.com/2d8n7

Yes you were. I on the other hand thought that the article crystalized
exactly what I was attempting to express. My interpretation remains as
follows:

1. Setting an object to nothing marks it as unused and able to participate
in the next GC sweep
2. Allocating 256 variants, 64KB of strings or 4096 arrays causes GC to set
a flag that says collect soon
3. On the next statement execution, the flag is checked and if set GC is
done

Items 2 and 3 come from this article which was also cited (by me) in our
conversation:
http://msdn.microsoft.com/msdnmag/issues/01/05/web/default.aspx

It feels like item 1 is the sticking point. You've asserted that this does
nothing to aid GC but offer no evidence to support that assertion. Yes, I
know, I've offered no evidence on counterpoint. I guess we'll have to agree
to disagree until someone can present some definitive proof.

It would be simple if I could find evidence of a memory leak. As our
intranet is built on ASP/JScript code that DOES NOT "dereference" objects, I
would think we would have noticed a memory leak by now.

I didn't mention anything about memory leaks. Apparently, your scripts with
implicit object dereferencing when the page goes out of scope works for you.

How do you propose I determine the success or failure?

It works, so I'd call that a success. If you want to determine whether
explicitly dereferncing an object can improve performance you could create
one script with explicit dereferncing and one without and track their memory
utilization in performance monitor. I'm sure there are other ways as well.

-Chris Hohmann

 

[Dave Anderson]

That's one environment. So I may agree that, since you have avoided
the "worthless" advice and it has not turned out to have adverse
effects, then it is certainly fine for you to continue doing so.

I know this thread is meandering a bit, but Chris was referring (or should I
spell it refering in here?) specifically to JScript. With VBScript,
virtually every resource instructs the use of Nothing assignment. There is
simply no consensus for dealing with GC in JScript. And I contend there is
no parallel.

However, in general recommendations for the majority of the
newsgroups, e.g. people who have myriad environments and possibly few
resources to test potential memory leak problems, I still don't feel
that the advice is worthless. If it saves one person from having a
memory leak issue that they can't track down (and it has happened to
many people, just search Google), then to me that is not worthless.

Again, I don't deny that it has been useful. I'm asking whether it still is.

After reading Eric Lippert's article, I got the nagging feeling that the
advice is being perpetrated thoughtlessly. I know guys who still code buffer
restrictions into their JCL because it USED TO BE NECESSARY, and despite the
fact that our JCL parser overrides those limits with larger values. At what
point to we insist that they stop using deprecated features? When do we stop
advocating "cargo cult programming"?
http://en.wikipedia.org/wiki/Cargo_cult_programming

If 14 characters really makes or breaks your "code size limitation"
problem, I'd say you are developing code which is too close to the
edge already, and that it is merely convenient that you find this
statement unnecessary.

I never said I find it unnecessary. I expressed an interest in knowing if it
still IS NECESSARY. I started this discussion because of Lippert's article,
not because we were pushing those limits.

I think you are considering this issue from a much more selfish
perspective than the rest of us. Which isn't a bad thing,
necessarily, but you're planning to generalize, and deem "worthless,"
advice -- based solely on your environment and observations. I don't
think it would be fair for the rest of us to start telling people
"don't bother setting objects to nothing."

Give me a break Aaron. I'm not deeming anything worthless, I'm asking if we
should, as a group, revisit our assumptions. I'm asking if it still has
relevance. Lippert suggests this is a reasonable question to ask.

Like you, I don't think it would be fair to start telling people such a
thing. But I am willing to ask if we need to continue advising them the
opposite. I would be thrilled if someone could demonstrate that it continues
to be a solution to a real, ongoing problem in version x+1. At least that
way, I could confidently give advice I "deem worthwhile".

I still think it's a good practice because there are still 3rd party
COM objects out there, being written by who knows who... better safe
than sorry, and all that.

I'm going to bite my toungue on this one.

And while you're there, might as well code consistently, even for those
statements that you allegedly "know" are "worthless."

You know that's an unfair distortion of my argument.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Aaron Bertrand - MVP]

Again, I don't deny that it has been useful. I'm asking whether it still
is.

As long as NT 4.0 still exists, yes it is.

At what
point to we insist that they stop using deprecated features?

When NT 4.0 no longer exists.

A

 

[Dave Anderson]

Another point I forgot to mention is that in IIS 5.0 and up, an
object is released as soon as you dereference it (in IIS 4 and
lower, release was keyed to the page, not the code).

If you recall, I provided an example which abstracted the object creation
and use to a Sub (nested in an error handling block), and asked if doing so
was sufficient, assuming no dereferencing took place. This would seem to
release the resources as quickly, IMO.

You're suggesting to not set = nothing, so the object isn't
released until the page goes out of scope.

I am not. Under my suggestion, it is released when the Sub ends. And the
article that launched this thread specifically addressed Nothing assignments
immediately before scope loss. So how does such an assignment help?

Depending on the content of the rest of the page, you might be
keeping those resources allocated a lot longer than they have
to be.

I never advocated bad design. I asked if Nothing assignments were
superfluous. We abstract as much as we can, for readability, maintenance and
performance reasons. This is a straw man.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

When NT 4.0 no longer exists.

As far as MS is concerned, tht is on December 31, 2004. I will reopen this
topic next year.
http://support.microsoft.com/default.aspx?scid=fh;[ln];LifeWin



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

I on the other hand thought that the article crystalized exactly
what I was attempting to express. My interpretation remains as
follows:

My interpretation is interlaced:

1. Setting an object to nothing marks it as unused and able to
participate in the next GC sweep

Variable:
Since the Nothing value is not intrinsic to JScript, setting it to *Nothing*
is nothing more than a value assignment -- no better than setting it to
Math.PI or "Bob" with respect to GC. Ditto for null assignments. Scope loss
is the only trigger for such marking.

Property:
The delete operator can immediately end the scope of an object property.

2. Allocating 256 variants, 64KB of strings or 4096 arrays causes GC
to set a flag that says collect soon

Agreed. I infer a "since the last sweep" in that item. And I read "array
slots" to be elements, not whole arrays.

3. On the next statement execution, the flag is checked and if set GC
is done

This may be our sticking point. When I first read "new statement", I thought
"new Operator", which seemed to make sense, given the connection between
objects and the need for GC. But now I'm not sure. The casual format of the
Q&A doesn't exactly make it clear that they meant "another statement"
instead of "new Operator".

I'll defer to you on this one, in which case, your string literal assignment
*may* trigger collection (but only in the rare instance that the flag is
set).

Items 2 and 3 come from this article which was also cited (by me) in
our conversation:
http://msdn.microsoft.com/msdnmag/issues/01/05/web/default.aspx

It feels like item 1 is the sticking point. You've asserted that this
does nothing to aid GC but offer no evidence to support that
assertion. Yes, I know, I've offered no evidence on counterpoint. I
guess we'll have to agree to disagree until someone can present some
definitive proof.

Agreed. No! Disagreed. No! Agreed. Pass!
http://tinyurl.com/39zj4

I didn't mention anything about memory leaks. Apparently, your
scripts with implicit object dereferencing when the page goes out of
scope works for you.

If not memory leaks, what would we attempt to ascertain by comparing the
two?

It works, so I'd call that a success. If you want to determine whether
explicitly dereferncing an object can improve performance you could
create one script with explicit dereferncing and one without and
track their memory utilization in performance monitor. I'm sure there
are other ways as well.

I suppose that depends on accepting your definition of "explicitly
dereferencing" in JScript, but I'll see if I have time to test it.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.