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/ar...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. 27  2630 
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" <GT**********@spammotel.com> wrote in message
news:er*************@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/ar...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.
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/ar...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.
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.
> 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
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.
"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:er*************@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/ar...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/infinitemonk...es/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
> 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?
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.
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/infinitemonk...es/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/infinitemonk...es/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.
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.
> 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
> 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
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
"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:OH*************@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/infinitemonk...es/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/infinitemonk...es/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/is...b/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
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.
> 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
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.
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.
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/is...b/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.
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.
"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:OX**************@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...b;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
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/is...b/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
Sorry, no real player. I'm sure it was funny though. 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?
We would be attempting to ascertain whether or not explicit dereferencing
has a lower memory utilization footprint that waiting for the object to go
out of scope. 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.
Yes it does. Although now we have KB164494 supporting my definition. Looking
forward to your findings.
Bob Barrows [MVP] wrote: 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
An excellent summarization. Such bugs as described in http://www.4guysfromrolla.com/webtech/060999-2.shtml will keep me
performing such practices as setting objects to Nothing until I write
my last line of code. This I consider a good example of another
metaphor: "defensive programming".
Microsoft has had it's share of so-called "regression bugs" http://www.sciencedaily.com/encyclop...ession_testing
wherein a bug in an older version of software is re-introduced in later
versions (often skipping versions). Such occurrences reinforce the
utility of defensive programming.
IMO the OP (and Eric Lippert) are merely fascinated with their
(apparently) recent discovery of the cargo cult metaphor. But the
metaphor has been in common use on the Internet for years prior to
_their_ discovery of the term, e.g.: http://groups.google.com/groups?q=ca...ax.UUCP&rnum=1
Nonetheless, to use yet another metaphor, just as
"To a child with a hammer, all the world looks like a nail.",
so those children among us who have only recently discovered the term
"cargo cult programming" are wildly eager to share with everyone their
newly-discovered "hammer" and possibly to use it to hammer other
programmers. Lippert and Microsoft in general are newbies to the
Internet however, so we can surely forgive their enthusiasm.
From another perspective, I would maintain that _all_ users of
Microsoft products are _necessarily_ "cargo cult" users because
Microsoft doesn't reveal their source code and we necessarily _cannot_
understand how their systems work. As a result, superstitious practices
abound in the Windows world ("Heck, I dunno; why don't you reboot the
system?").
Indeed, to be intellectually honest, _everyone_ is a "cargo cult"
person, because _everyone_ uses words and tools which they do not
understand (at some level), yet which they trust to work (e.g., I would
be hard-pressed to build an automatic transmission for my car, even
given the scrap steel necessary to make the parts). So we're merely
talking about the _degree_ to which we are "cargo cult" programmers. But
to the best of my knowledge there is no consistent "cargo cult scale"
that we can neasure differences with, and so, at that point the metaphor
ceases to be useful.
Good Luck,
Michael D. Kersey
"Bob Barrows [MVP]" wrote in message
news:u4**************@tk2msftngp13.phx.gbl...
: Instead we get people like Eric treating us as if we are idiots who
: don't understand scope and "how COM works".
I understand scope completely. Open the cabinet, remove the bottle, unscrew
the cap, take a swig, swish, gargle and spit. Simple.
Forgot to Set cuboard = Nothing
You didnt put it back in
"Roland Hall" <nobody@nowhere> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... "Bob Barrows [MVP]" wrote in message
news:u4**************@tk2msftngp13.phx.gbl...
: Instead we get people like Eric treating us as if we are idiots who
: don't understand scope and "how COM works".
I understand scope completely. Open the cabinet, remove the bottle,
unscrew the cap, take a swig, swish, gargle and spit. Simple.
"Don Grover" wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
: Forgot to Set cuboard = Nothing
: You didnt put it back in
That's what wives are for! *ducks and runs*
Michael D. Kersey wrote:
An excellent summarization...
Indeed. It is the most persuasive argument I have heard to date on either
side of the issue. On the other hand...
...IMO the OP (and Eric Lippert) are merely fascinated with
their (apparently) recent discovery of the cargo cult metaphor.
But the metaphor has been in common use on the Internet for
years prior to _their_ discovery of the term, e.g.:
[URL replaced with http://tinyurl.com/yvehu ]
I cannot speak for Lippert, but this is certainly not my affliction. And the
dismissiveness of this response is insulting to anyone who believes in
challenging his own assumptions. It discounts the very notion that
revisiting assumptions has any worth at all. And I think that is sad.
...From another perspective, I would maintain that _all_ users
of Microsoft products are _necessarily_ "cargo cult" users
because Microsoft doesn't reveal their source code and we
necessarily _cannot_ understand how their systems work. As a
result, superstitious practices abound in the Windows world
("Heck, I dunno; why don't you reboot the system?").
This more or less** fits within the generalized "group of people making
obeisance to something that it is obvious they do not comprehend"
(http://en.wikipedia.org/wiki/Cargo_cult), but the following does not:
Indeed, to be intellectually honest, _everyone_ is a "cargo
cult" person, because _everyone_ uses words and tools which
they do not understand (at some level), yet which they trust
to work (e.g., I would be hard-pressed to build an automatic
transmission for my car, even given the scrap steel necessary
to make the parts).
I think this stretches the analogy too far. Using tools is not shallow
emulation. Just consider the source of the analogy, and see if it fits a
modern proxy: If a U.S. pullout occurred today in South Korea, do you think
the Koreans would perform ritualistic practices to entice back those
mysterious jets that once flew out of Osan? The populous, after all,
understands little (if anything) about the inner workings of F-16 fighter
jets.
So we're merely talking about the _degree_ to which we are
"cargo cult" programmers. But to the best of my knowledge
there is no consistent "cargo cult scale" that we can neasure
differences with, and so, at that point the metaphor ceases
to be useful.
I disagree with the assertion that we are all cargo cult programmers. I
don't believe the cargo cult analogy applies to those of us who are
comfortable with having been wrong, but uncomfortable with being wrong.
Intellectual curiosity an the will to challenge one's own beliefs count for
something.
**I say more or less because I believe there is a distinction between
"cannot" and "do not". Many of us are quite capable of understanding these
things, but lack the access to (or even interest in) the specifics. That is
not the same as failing to comprehend something, IMO.
--
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 Barrows [MVP] wrote: Instead we get people like Eric treating us as if we are idiots
I do wish to retract this as far as Eric's blog itself is concerned. I had
unfairly lumped him in with some people I had encountered in the past who
DID treat those of us who espoused explicit object creation and destruction
as "idiots". Also, at least one of the respondants to the blog does exhibit
this attitude.
I also want to say that, except for ADO objects, I am not as religious about
this as my prior posts may indicate. I sometimes fail to explicitly destroy
my xml domdocument and fso objects. I guess my thinking on this subject has
undergone some alteration ...
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Erik T. Nomad |
last post by:
I've created a link that will enable the reader of any page on my
website to click it, enter an e-mail address, and have it arrive in
that inbox with a hyperlink to the site. However, I'm...
|
by: grakat |
last post by:
The "frames are evil" mantra is often heard - I've said it myself -,
but can someone tell me how a framed site works in an aural browser or
for that matter, any browser other than the normal GUI...
|
by: 胡岳偉（Yueh-Wei Hu） |
last post by:
Hi all,
I have 2 questions about template function as friends in template
classes. I don't know why, and hope someone could help me.
...
|
by: Yueh-Wei Hu |
last post by:
Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:
==============================================================
> > Question 1:
> >...
|
by: Ruben Campos |
last post by:
Some questions about this code:
template <typename T> class MyTemplate;
template <typename T> MyTemplate <T> operator- (const MyTemplate <T> &
object);
template <typename T> MyTemplate <T>...
|
by: Tony Johansson |
last post by:
Hello experts!
Assume I have this class definition of class ListElem.
I'm a bit unsure how to interpret when you put friend declaration in public,
protected and private section of a class...
|
by: Zeng |
last post by:
It's so messy w/o the "friend" relationship. Does anyone know why it was
not supported in C#. It's almost about as bad as it doesn't support the
inheritance hierarchy and method reference...
|
by: Adam Badura |
last post by:
I have code like this
template<int size> big_int {
/* ... */
template<int size2> friend class big_int<size2>;
};
What I wanted to achive is to be able to easly convert different sized...
|
by: Immortal_Nephi |
last post by:
I want to show you an example how two classes can have relationship
instead of an inheritance. The inheritance is not an option if you
want to define two classes.
The relationship between two...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
