Revisiting an old friend: Set oRS = Nothing

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
Wed May 05 13:36:08 CDT 2004

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

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/




"Dave Anderson" <GTSPXOESSGOQ@spammotel.com> wrote in message
news:er$ee8sMEHA.268@TK2MSFTNGP11.phx.gbl...
> 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.
>
>

Bob
Wed May 05 14:08:10 CDT 2004

Dave Anderson wrote:
> 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

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Dave
Wed May 05 14:11:58 CDT 2004

Aaron Bertrand - MVP wrote:
> 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
Wed May 05 15:00:27 CDT 2004

> 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
Wed May 05 16:12:11 CDT 2004

Aaron Bertrand - MVP wrote:
>> 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.

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
Wed May 05 20:42:27 CDT 2004

"Dave Anderson" <GTSPXOESSGOQ@spammotel.com> wrote in message
news:er$ee8sMEHA.268@TK2MSFTNGP11.phx.gbl...
> 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
Wed May 05 22:48:04 CDT 2004

> 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
Thu May 06 09:34:37 CDT 2004

Aaron Bertrand [MVP] wrote:
>> 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?

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
Thu May 06 10:02:31 CDT 2004

Chris Hohmann wrote:
>
> 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
Thu May 06 10:34:13 CDT 2004

Aaron Bertrand [MVP] wrote:
>
> 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
Thu May 06 10:49:42 CDT 2004

> 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
Thu May 06 10:49:42 CDT 2004

> 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
Thu May 06 11:12:13 CDT 2004

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
Thu May 06 14:03:30 CDT 2004

"Dave Anderson" <GTSPXOESSGOQ@spammotel.com> wrote in message
news:OHzCqs3MEHA.808@tk2msftngp13.phx.gbl...
> Chris Hohmann wrote:
> >
> > 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.

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.


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

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.


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

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.


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

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
Thu May 06 14:22:42 CDT 2004

Aaron Bertrand - MVP wrote:
>> 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.

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
Thu May 06 14:32:11 CDT 2004

> 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
Thu May 06 14:36:46 CDT 2004

Aaron Bertrand - MVP wrote:
> 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
Thu May 06 14:41:53 CDT 2004

Aaron Bertrand - MVP wrote:
>
>> At what point to we insist that they stop using deprecated features?
>
> 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
Thu May 06 15:34:33 CDT 2004

Chris Hohmann wrote:
>
> 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


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


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

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.

Bob
Thu May 06 16:01:08 CDT 2004

I still can't get past this:

The VB/VBA documentation has always stated that COM objects are dereferenced
when they go out of scope. When Eric says: "The script engine will
automatically clear those variables when they go out of scope", he isn't
saying anything that the docs haven't said for the last umpteen years.

Yet bugs have been documented that have been corrected by explicitly
destroying them. A couple people on that blog page talked about the old DAO
Database object bug. Another referred to the intemittent IIS failures that
were corrected by explicit cleanup of ADO connection objects. This tells me
that COM _never behaved the way it was supposed to_. Why am I supposed to
all of a sudden start trusting it to behave correctly just because we have
another OS or another version of IIS? To me the burden of proof is rather
high, and would have to involve explaining how the previous failures
occurred and what's been done to prevent them. Instead we get people like
Eric treating us as if we are idiots who don't understand scope and "how COM
works".

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Chris
Thu May 06 19:15:13 CDT 2004

"Dave Anderson" <GTSPXOESSGOQ@spammotel.com> wrote in message
news:OXLeMm6MEHA.1608@TK2MSFTNGP12.phx.gbl...
> > 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.

From KB164494
http://support.microsoft.com/default.aspx?scid=kb;en-us;164494

"The following script demonstrates the problem. When you set the object
reference to null, the object is marked as available for garbage collection,
but it is not released until the garbage collector runs or the script engine
is destroyed: "

So KB164494 in combination with the JScript GC article seems to uphold my
interpretation:
1. Setting object to null marks the object for GC
2. Variant/string/array slot allocations cause GC set the "collect soon"
flag
3. The above flag is checked on the next statement and if it's set, GC is
run

I'm almost positive we've been done this road before.


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

Yes. That's what I get for not cuttting-and-pasting. I don't like it when
the formatting get's carried over.


> > 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
t