Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Nothing
17 views
Skip to first unread message
JJ
Apr 29, 2012, 5:08:16 PM4/29/12
to
Sub Include(ByVal includefile)
Dim fso, s, f
Set fso = CreateObject("Scripting.FileSystemObject")
If fso.FileExists(includefile) Then
Set f = fso.OpenTextFile(includefile, 1, False)
s = f.ReadAll
f.Close
Set f = Nothing
ExecuteGlobal s
End If
End Sub
Is using Nothing above actually helpful in any way? Isn't f
deallocated as soon as the Sub ends and the variable goes out of
scope? If it is good to do, why not also 'Set fso = Nothing'?
Dim fso, s, f
Set fso = CreateObject("Scripting.FileSystemObject")
If fso.FileExists(includefile) Then
Set f = fso.OpenTextFile(includefile, 1, False)
s = f.ReadAll
f.Close
Set f = Nothing
ExecuteGlobal s
End If
End Sub
Is using Nothing above actually helpful in any way? Isn't f
deallocated as soon as the Sub ends and the variable goes out of
scope? If it is good to do, why not also 'Set fso = Nothing'?
GS
Apr 29, 2012, 5:26:28 PM4/29/12
to
JJ presented the following explanation :
Well, if this is code you did not create then the person who did create
it is either lazy, undisciplined, or both!
Here's my rules on this...
1. If I explicitly create an object, (as you have here) I explicitly
destroy it when done with it.
..meaning that here both 'fso' and 'f' should get explicitly destroyed.
2. If I implicitly create an object, I leave it to VB to implicitly
destroy when it runs out of scope. (ie: Dim oColl As New Collection)
3. Know when to use explicit or implicit. If in doubt ALWAYS use
explecit.
Note that anything left to be done implicitly ALWAYS requires extra
processing by VB/A/Script, adding to runtime overhead. There's more
disadvantages to implicitly creating objects and so good programming
paractice prefers using explicit in the same spirit as the 'Option
Explicit' statement is used!<IMO>
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
it is either lazy, undisciplined, or both!
Here's my rules on this...
1. If I explicitly create an object, (as you have here) I explicitly
destroy it when done with it.
..meaning that here both 'fso' and 'f' should get explicitly destroyed.
2. If I implicitly create an object, I leave it to VB to implicitly
destroy when it runs out of scope. (ie: Dim oColl As New Collection)
3. Know when to use explicit or implicit. If in doubt ALWAYS use
explecit.
Note that anything left to be done implicitly ALWAYS requires extra
processing by VB/A/Script, adding to runtime overhead. There's more
disadvantages to implicitly creating objects and so good programming
paractice prefers using explicit in the same spirit as the 'Option
Explicit' statement is used!<IMO>
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
JJ
Apr 29, 2012, 5:41:21 PM4/29/12
to
On Apr 29, 3:26 pm, GS <g...@somewhere.net> wrote:
>
> Here's my rules on this...
>
> 1. If I explicitly create an object, (as you have here) I explicitly
> destroy it when done with it.
>
>
> Here's my rules on this...
>
> 1. If I explicitly create an object, (as you have here) I explicitly
> destroy it when done with it.
>
> Note that anything left to be done implicitly ALWAYS requires extra
> processing by VB/A/Script, adding to runtime overhead.
That's it???
> processing by VB/A/Script, adding to runtime overhead.
GS
Apr 29, 2012, 5:57:19 PM4/29/12
to
After serious thinking JJ wrote :
Where's the rest of my post?
Isn't that enough?
Isn't that enough?
Mayayana
Apr 29, 2012, 7:01:43 PM4/29/12
to
> That's it???
I'm with Garry, but it's "controversial". People have
different opinions. I always set things to Nothing. In
general, WSH will take care of it, but there are exceptions,
and it's a good habit to clean up after oneself. So why
strategize saving tiny bits of work? Setting to Nothing
when the object is already gone does no harm.
Where appropriate I'd create FSO globally and release
it globally, since there's a good chance it will be needed
elsewhere in the script.
Todd Vargo
Apr 30, 2012, 4:17:04 AM4/30/12
to
its variables and objects are released. When the script ends, all
variables and objects are released.
What exceptions are you referring to? Please stick to technical
information and exclude opinion.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Mayayana
Apr 30, 2012, 9:49:21 AM4/30/12
to
| AFAIK, the technical answer remains, when a Sub/Function routine ends,
| its variables and objects are released. When the script ends, all
| variables and objects are released.
|
| What exceptions are you referring to? Please stick to technical
| information and exclude opinion.
|
You could find this information yourself easily enough.
| its variables and objects are released. When the script ends, all
| variables and objects are released.
|
| What exceptions are you referring to? Please stick to technical
| information and exclude opinion.
|
One example is Eric Lippert's "famous" rant. He opposes
setting objects to Nothing, but nevertheless points out
a couple of issues.
http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/122259.aspx
See explanation #3, #4 and the comments section.
Another example is ActiveX EXEs. I'm not certain of how
their "life" works, but in my experience they seem to keep
running if not explicitly set to nothing. An ActiveX EXE is
out-of-process, meaning it runs in its own process, separate
from the script. Most objects are in-process, so they get
cleaned up by the memory manager when WSH quits.
So there's the issue of excess memory use in large scripts,
where it makes sense to clean up as one goes along in order
to keep memory usage down. And there's also the issue of
possible oddball situations that might not fit the model.
I would be inclined to turn the question around: If you can't
absolutely promise and prove that there is never an advantage
in setting to Nothing, then why not just do it? What's the big
deal about adding that line?
* It's harmless.
* In some cases it can help.
* In general it's a good idea to pay attention to the mess
one creates and clean it up. That promotes clear thinking
and clear code. And in other languages it's often more
important. Or to put it another way: Just because WSH is
designed to change our diiapers for us doesn't mean we
can't use the toilet like proper adults. :)
I've never understood the strong feelings against setting
to Nothing. One protest is demonstrated in the comments
at the link above: Smug statements that people who set to
Nothing don't understand scope. But that's really a different
issue.
So what's the big deal? Is it laziness? Do the people at MS
feel insulted that their memory management code is not being
trusted? And your own attitude: A haughty demand of proof.
To me that sounds like the fat person who's warned about eating
cheesecake and angrily retorts, "Show me someone who died
from cheesecake!" ...If they don't want to know about the
risks of fat, they never will. If they want to know they can
do their own research and make their own decisions. Maybe
they'll decide to continue eating cheesecake, but at least they
won't be doing it as a guttonous ostrich.
As far as I'm concerned, the "technical answer" AKA the official
position is often not the best way to look at things, and in
the case of Microsoft it's often a blend of marketing, strategy
and actual facts. (No, I'm not going to document that statement
for you. You'll just have to decide for yourself. :)
Mayayana
Apr 30, 2012, 1:29:25 PM4/30/12
to
| Is using Nothing above actually helpful in any way? Isn't f
| deallocated as soon as the Sub ends and the variable goes out of
| scope? If it is good to do, why not also 'Set fso = Nothing'?
I realized your question was in reference to the
| deallocated as soon as the Sub ends and the variable goes out of
| scope? If it is good to do, why not also 'Set fso = Nothing'?
sample I posted earlier. I probably threw that
together. "Air code". Personally I would usually set
both objects to Nothing as soon as possible, but
usually when I'm using a sub like that I've got a
global instance of FSO that's going for the duration
of the script, so that I wouldn't need to create an
instance in the sub.
In any case, the URL I posted earlier provides as
complete a discussion as any I've seen of why you
should never set to Nothing... but maybe you should. :)
http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/122259.aspx
GS
Apr 30, 2012, 1:31:14 PM4/30/12
to
Mayayana submitted this idea :
After reading this article, I conclude that for some people it just
doesn't matter how much extra processing their projects require at
runtime because it's easier to be lazy and undisciplined than adopt
good coding practices! To each their own...
doesn't matter how much extra processing their projects require at
runtime because it's easier to be lazy and undisciplined than adopt
good coding practices! To each their own...
Todd Vargo
Apr 30, 2012, 8:13:10 PM4/30/12
to
and #4, are based on speculation. What he actually says in both
instances is that setting to nothing in vbscript is unnecessary because
there is no proof the GC will unload in incorrect order. (That is the
way I read it..YMMV.) Its not about laziness. We just want to know fact
from opinion. So far, all we read on this topic over the past umpteen
years is opinion or speculation.
Mayayana
Apr 30, 2012, 9:54:13 PM4/30/12
to
| Sorry, I believe you are misreading his "famous" rant. Explanations #3
| and #4, are based on speculation. What he actually says in both
| instances is that setting to nothing in vbscript is unnecessary because
| there is no proof the GC will unload in incorrect order. (That is the
| way I read it..YMMV.) Its not about laziness. We just want to know fact
| from opinion. So far, all we read on this topic over the past umpteen
| years is opinion or speculation.
|
"The only way to work around the bug is to explicitly clean up the objects
| and #4, are based on speculation. What he actually says in both
| instances is that setting to nothing in vbscript is unnecessary because
| there is no proof the GC will unload in incorrect order. (That is the
| way I read it..YMMV.) Its not about laziness. We just want to know fact
| from opinion. So far, all we read on this topic over the past umpteen
| years is opinion or speculation.
|
in the right order before they go out of scope.
And indeed, there were widely-used ADO objects that had this kind of bug."
That's a quote from #4. There was a specific bug. It was
well known. Eric's interpretation is that this single real bug
resulted in people mistakenly believing that setting to Nothing
is necessary all the time. My interpretation, as I said above,
is that generally WSH will clean up, but there are exceptions.
An older version of ADO was one example. It could happen
again.
#3 is not talking about order. It's just talking about the idea
of releasing resources when you're done with them. In #3 Eric
actually says that releasing when things are
not needed is a good design. (Not that I particularly value
what Eric Lippert says, but you wanted official.) Again, he's
not denying that there's a good reason for that approach.
What he is saying is that he regards setting things to Nothing
at the end of a sub as cluttered and pointless. And with his
usual condescending tone, he's speculating about what usage
of setting to Nothing might have led to that behavior among us
halfwit riff-raff. Somehow you've jumped from the idea that
setting to Nothing at the end of a sub is pointless and silly (what
Eric *is* saying) to generalizing that setting to Nothing
is pointless, period (which Eric never said).
If you said that you don't think it's worth the trouble and
you're going to take your chances for convenience, I'd say
suit yourself. In the majority of cases it won't matter, and
most PCs these days have far more RAM than anyone needs.
But you insist on the false claim that WSH always takes care
of all memory use and that one *should not* ever try to
manage it.
Mayayana
Apr 30, 2012, 10:29:56 PM4/30/12
to
Just to clarify, in hopes of avoiding unnecessary
debate here, this is a direct quote from Eric L. in
the comments section of that page:
"However, just to clarify, my beef is specifically with people who clear
object variables IMMEDIATELY before they go out of a local scope. It is a
really good idea to clear variables that hold expensive resources as soon as
you're done with them if you're going to go do other stuff before they fall
out of scope."
So can we agree that the only point at issue
is setting to Nothing at the end of a sub where the object
was created, or at the end of a script? In that case
I do it mainly for clarity in my code and to maintain good
habits in coding. (I like to be clear about what resources
are in use. VBS makes it too easy to be sloppy.) But I agree
that that usage of setting to Nothing is officially not necessary.
In a funny sort of way it's almost a moral issue to me. It's
like picking up litter from a hotel room floor before I check
out. I know the maid will do it but I feel that it's not her
job. It's my mess. Whether or not I trust the maid to do it
never comes up in my mind. It's my responsibility, not hers. :)
debate here, this is a direct quote from Eric L. in
the comments section of that page:
"However, just to clarify, my beef is specifically with people who clear
object variables IMMEDIATELY before they go out of a local scope. It is a
really good idea to clear variables that hold expensive resources as soon as
you're done with them if you're going to go do other stuff before they fall
out of scope."
So can we agree that the only point at issue
is setting to Nothing at the end of a sub where the object
was created, or at the end of a script? In that case
I do it mainly for clarity in my code and to maintain good
habits in coding. (I like to be clear about what resources
are in use. VBS makes it too easy to be sloppy.) But I agree
that that usage of setting to Nothing is officially not necessary.
In a funny sort of way it's almost a moral issue to me. It's
like picking up litter from a hotel room floor before I check
out. I know the maid will do it but I feel that it's not her
job. It's my mess. Whether or not I trust the maid to do it
never comes up in my mind. It's my responsibility, not hers. :)
Todd Vargo
Apr 30, 2012, 10:46:44 PM4/30/12
to
On 4/30/2012 9:54 PM, Mayayana wrote:
> | Sorry, I believe you are misreading his "famous" rant. Explanations #3
> | and #4, are based on speculation. What he actually says in both
> | instances is that setting to nothing in vbscript is unnecessary because
> | there is no proof the GC will unload in incorrect order. (That is the
> | way I read it..YMMV.) Its not about laziness. We just want to know fact
> | from opinion. So far, all we read on this topic over the past umpteen
> | years is opinion or speculation.
> |
>
> "The only way to work around the bug is to explicitly clean up the objects
> in the right order before they go out of scope.
> And indeed, there were widely-used ADO objects that had this kind of bug."
>
> That's a quote from #4. There was a specific bug. It was
> well known. Eric's interpretation is that this single real bug
> resulted in people mistakenly believing that setting to Nothing
> is necessary all the time. My interpretation, as I said above,
> is that generally WSH will clean up, but there are exceptions.
> An older version of ADO was one example. It could happen
> again.
Obviously not known well enough to actually identify it beyond the
> | Sorry, I believe you are misreading his "famous" rant. Explanations #3
> | and #4, are based on speculation. What he actually says in both
> | instances is that setting to nothing in vbscript is unnecessary because
> | there is no proof the GC will unload in incorrect order. (That is the
> | way I read it..YMMV.) Its not about laziness. We just want to know fact
> | from opinion. So far, all we read on this topic over the past umpteen
> | years is opinion or speculation.
> |
>
> "The only way to work around the bug is to explicitly clean up the objects
> in the right order before they go out of scope.
> And indeed, there were widely-used ADO objects that had this kind of bug."
>
> That's a quote from #4. There was a specific bug. It was
> well known. Eric's interpretation is that this single real bug
> resulted in people mistakenly believing that setting to Nothing
> is necessary all the time. My interpretation, as I said above,
> is that generally WSH will clean up, but there are exceptions.
> An older version of ADO was one example. It could happen
> again.
generalized "widely-used ADO objects" description. Was the bug long ago
patched? Are the specific ADO objects in question still in use today?
Which OS, database, etc.? These *are* the facts we are after. Without
these essential facts, all we keep seeing is the same old opinions based
on folklore (as Eric called it).
>
> #3 is not talking about order. It's just talking about the idea
> of releasing resources when you're done with them. In #3 Eric
> actually says that releasing when things are
> not needed is a good design. (Not that I particularly value
> what Eric Lippert says, but you wanted official.) Again, he's
> not denying that there's a good reason for that approach.
> What he is saying is that he regards setting things to Nothing
> at the end of a sub as cluttered and pointless. And with his
> usual condescending tone, he's speculating about what usage
> of setting to Nothing might have led to that behavior among us
> halfwit riff-raff. Somehow you've jumped from the idea that
> setting to Nothing at the end of a sub is pointless and silly (what
> Eric *is* saying) to generalizing that setting to Nothing
> is pointless, period (which Eric never said).
>
> If you said that you don't think it's worth the trouble and
> you're going to take your chances for convenience, I'd say
> suit yourself. In the majority of cases it won't matter, and
> most PCs these days have far more RAM than anyone needs.
> But you insist on the false claim that WSH always takes care
> of all memory use and that one *should not* ever try to
> manage it.
*should not* ever try to manage it." That is a total fabrication from
your imagination. Just stick to the facts. I'm not against it, I just
wanted to finally see a response based on fact not the same old
regurgitated opinions.
The search goes on.
Todd Vargo
Apr 30, 2012, 10:57:43 PM4/30/12
to
GS
Apr 30, 2012, 11:05:07 PM4/30/12
to
To add to your comments (all of which I agree)...
I used to thing along the same lines as Eric once upon a time. As I
grew my skills as a developer I was often criticized for not 'cleaning
up my messes' when using objects.
I made a point to look into this with some tenacity, relentless to
disprove my scoffers. Well.., I failed to be able to do so! Every test
I did proved them right because of the extra processing they said was
happening with implicit management of objects. While it's quite true
that on a one-by-one basis the 'messes' left to implicity to cleanup
are minimal to insignificant, the cummulative effect over the runtime
of an app can impact performance significantly under various
circumstances.
Since 'technical facts' are a point of contention, here's some facts I
discovered that contribute to my current 'opinion' on this topic:
Every test included implicit object management followed by explicit
object management via commenting/uncommenting the appropriate lines of
code in the test procedures.
Every test for implicit management ALWAYS (and without exeption) took
longer.
Every test for explicit management released the resources
immediately. The implicit tests did not release resources at the end of
the procedures even though the objects fell out of scope. (Hmm.., this
'fact' certainly doesn't concur with the popular misconception that
states to the contrary) No problem with today's price for RAM, right?
The resource usage during runtime gradually increased after each test
for implicit management. Usage for the explicit tests increased during
procedure runtime and returned to the same point as before the
procedure was run.
One test included shutting down (Ending) the app while an implicit
object was left to be cleaned up by implicitly. The app closed but it
still was running according to Task Manager. It didn't even
'eventually' cleanup and so I had to end it manually via Task Manager.
I concluded from my tests that the scoffers were indeed giving me good
advice! I also concluded that contrary to popular misconception that
memory is always released when an app quits when implicit management is
used, it apparently IS NOT the case. Thus, it is my opinion that
laziness AND lack of discipline abounds where this topic is
concerned!<g>
I invite anyone to make their own tests so whatever
'opinion/speculation' they support has some real world supporting
'facts'! Making use of the various developer tools at your disposal is
encouraged, but Task Manager will suffice in most cases.
The 'fact' remains that there's more than enough cons about being lazy
and undisciplined in regard to this topic to substantiate/justify
avoiding implicit management as much as possible. But then, I must try
to remember that VBScript was created for non-programmers and so
expecting good programming practices might be asking too much from some
people!
I used to thing along the same lines as Eric once upon a time. As I
grew my skills as a developer I was often criticized for not 'cleaning
up my messes' when using objects.
I made a point to look into this with some tenacity, relentless to
disprove my scoffers. Well.., I failed to be able to do so! Every test
I did proved them right because of the extra processing they said was
happening with implicit management of objects. While it's quite true
that on a one-by-one basis the 'messes' left to implicity to cleanup
are minimal to insignificant, the cummulative effect over the runtime
of an app can impact performance significantly under various
circumstances.
Since 'technical facts' are a point of contention, here's some facts I
discovered that contribute to my current 'opinion' on this topic:
Every test included implicit object management followed by explicit
object management via commenting/uncommenting the appropriate lines of
code in the test procedures.
Every test for implicit management ALWAYS (and without exeption) took
longer.
Every test for explicit management released the resources
immediately. The implicit tests did not release resources at the end of
the procedures even though the objects fell out of scope. (Hmm.., this
'fact' certainly doesn't concur with the popular misconception that
states to the contrary) No problem with today's price for RAM, right?
The resource usage during runtime gradually increased after each test
for implicit management. Usage for the explicit tests increased during
procedure runtime and returned to the same point as before the
procedure was run.
One test included shutting down (Ending) the app while an implicit
object was left to be cleaned up by implicitly. The app closed but it
still was running according to Task Manager. It didn't even
'eventually' cleanup and so I had to end it manually via Task Manager.
I concluded from my tests that the scoffers were indeed giving me good
advice! I also concluded that contrary to popular misconception that
memory is always released when an app quits when implicit management is
used, it apparently IS NOT the case. Thus, it is my opinion that
laziness AND lack of discipline abounds where this topic is
concerned!<g>
I invite anyone to make their own tests so whatever
'opinion/speculation' they support has some real world supporting
'facts'! Making use of the various developer tools at your disposal is
encouraged, but Task Manager will suffice in most cases.
The 'fact' remains that there's more than enough cons about being lazy
and undisciplined in regard to this topic to substantiate/justify
avoiding implicit management as much as possible. But then, I must try
to remember that VBScript was created for non-programmers and so
expecting good programming practices might be asking too much from some
people!
GS
Apr 30, 2012, 11:42:47 PM4/30/12
to
Oops! Typo...
> To add to your comments (all of which I agree)...
I used to thinK along the same lines as Eric once upon a time.
ralph
May 1, 2012, 2:19:46 AM5/1/12
to
results I discovered when I tested the difference between implicit and
explicit management. But I can't provide too many specifics as it has
been many a moon since I played with it, so I'll likely fail the "just
the facts" requirement by Mr. Vargo. <g>
When I started programming in VB* I ran into the same sort of
scoffing, but in my shop just the opposite. I came from C so I was
down-right anal about 'clean-up'. I was ridiculed for wasting space on
useless Nothings. Their view made sense, but I tested anyway. Actually
was interested in another aspect of VB's internals* at the time.
Object management was sort of secondary, but the results were
identical to GS's and rather surprising. (I'm always surprised when
I'm close to correct on anything. <g>)
Part of Eric's and other's problem when analyzing this subject is they
forget that while the front-end 'script' we call VB* is very much
"ALGOrithmic", a la C, the internal engine (parser, compiler,
interpreter, whatever) is actually stack-based, and not
function-based. So there is a tendency to think of VB* as behaving
exactly like C because of its syntax.
In a C function a locally declared object (or automatic variable) is
placed on 'The' stack and managed at the function level. That stack is
"setup an cleared" as defined by that function. In a sense the
compiler takes care of it whether you wanted it to or not.
In VB* something rather different is going on. VB* is made up of
several 'stacks' (dictionaries, caches, lists, ...) that handle
temporary variables, global names, objects, ..., procedures themselves
are just data chunks in a dictionary. The rest is essentially just a
lot of bookkeeping.
VB* does have one major advantage it is about as linear and
straight-line as you can get. When it gets the 'next' instruction, it
does it. (Well the 'next' might be fetch 'n hold, or ... but let's
keep it simple for now. <g>). That is why I came to the same
conclusion as GS - Explicit instructions (eg, destruction) are simply
did 'n done. Period. Implicit requires extra bookkeeping.
Now the disclaimers... <g>
VB* - by this I meant all the visual basic dialects running as
intermediates for a VM, etc. ie, the pcode (opcode/excode).
Confusion often comes about when working with 'VB internals' because
the big brother VB is often compiled to native code. In this case you
are not looking at translated or transcribed pcode, what you are
seeing is pcode compiled into pre-processed C code. This can be
misleading, eg, Procedure Data Objects get turned into 'Functions'.
And you will find a great deal of information on VB's "internals"
based on what someone found in the native compiled code, but that
isn't quite true of pcode.
VBScript has far less in common with others, but the internal workings
at the intermediate level is the same. (Well, make that very similar.
VBScript takes some short-cuts.)
*The other internals aspect I was researching was the bloating problem
when VB* was made executable or during runtime. These changes in size
occurred even if no obvious changes had been made to the code itself.
Even more baffling was that it would just as often seemingly 'correct'
itself and shrink back to some original size. This is exactly the same
phenomena that GS reported, I too felt it was due to bookkeeping
overhead.
However, I should mention that I'm well aware that all this testing
and playing went on some 10-15 years ago; back when CPU's were far far
slower, and 4 gig of ram and a 250 meg HD was a super computer <g>. I
wonder if one can still measure the differences today? And VB* itself
is far more optimized than the VB/VBA's (3, 4, and 5) I played with.
If anyone wants to argue that typing all those extra "Nothings" isn't
worth the few extra clicks of VB bookkeeping - they'll get no argument
from me.
As for the rest. I too have been burned on occasional with implicitly
declared objects in external libraries and when using Automation. (And
with compiled VB as well.) Not often and I'd be hard pressed to come
up with a specific example. But it happened and I just prefer to not
go there again - whether by superstition or fact.
-ralph
Mayayana
May 1, 2012, 10:21:55 AM5/1/12
to
Interesting stuff. I tend to groan a bit when this
topic comes up, but you and Garry have presented
issues that I didn't suspect.
As noted, CPUs and RAM can cover a lot of sloppiness
these days, but in my experience, optimizing VBS is still
worthwhile, simply because WSH/scrrun.dll are extremely
inefficient to begin with. And VBS seems to have some
kind of resource limit. I find that the more complex a
script gets, the more efficient it will be to use VB instead
of VBS. Probably a lot of that is the basics, like the
inefficiency of variants, but there also seems to be a
sort of cumulative problem: As the operations get bigger,
the script gets slower in greater proportion.
--
--
"ralph" <nt_cons...@yahoo.com> wrote in message
news:63pup71gulr2n1ra4...@4ax.com...
topic comes up, but you and Garry have presented
issues that I didn't suspect.
As noted, CPUs and RAM can cover a lot of sloppiness
these days, but in my experience, optimizing VBS is still
worthwhile, simply because WSH/scrrun.dll are extremely
inefficient to begin with. And VBS seems to have some
kind of resource limit. I find that the more complex a
script gets, the more efficient it will be to use VB instead
of VBS. Probably a lot of that is the basics, like the
inefficiency of variants, but there also seems to be a
sort of cumulative problem: As the operations get bigger,
the script gets slower in greater proportion.
--
--
"ralph" <nt_cons...@yahoo.com> wrote in message
news:63pup71gulr2n1ra4...@4ax.com...
GS
May 1, 2012, 11:03:06 AM5/1/12
to
The tests I did happened in 2005 with whatever version of VB* was
available at the time. So to Ralph, it appears nothing has changed
since you did your tests. Also, thanks for providing the additional
info...
available at the time. So to Ralph, it appears nothing has changed
since you did your tests. Also, thanks for providing the additional
info...
Todd Vargo
May 1, 2012, 5:23:16 PM5/1/12
to
On 5/1/2012 11:03 AM, GS wrote:
> The tests I did happened in 2005 with whatever version of VB* was
> available at the time. So to Ralph, it appears nothing has changed since
> you did your tests. Also, thanks for providing the additional info...
>
Great discussions everyone. Interestingly enough, after all these years,
> The tests I did happened in 2005 with whatever version of VB* was
> available at the time. So to Ralph, it appears nothing has changed since
> you did your tests. Also, thanks for providing the additional info...
>
and with several people independently performing similar testing (MVPs
included), not one person seems to have documented exact details about
their work. Only generalizations seem to be remembered now. Don't get me
wrong, I don't doubt that testing took place. We have revisited this
several times over the years. It just seems weird that we can not find
anything published with specific details of the tests performed (or even
squirreled away by those who performed the testing).
GS
May 1, 2012, 7:09:13 PM5/1/12
to
Todd Vargo presented the following explanation :
It's probably a case of there not being much to publish except
testimony of peoples findings (ergo details/results of their tests).
Most of my inspiration to test came from revered members of the VB/VBA
forums and so I did my own tests to see for myself. Up until one has
hard evidence of what's going on under the hood when we let use of
implicity creep into our programming discipline, it is really an eye
opener to 'self-discover' that the assertions of others are not really
'opinions' or 'speculations' at all. What I find more unfortunate is
that it's harder to find 'official' documentation. Thankfully, testing
is easily enough done without elaborate procedures to see the results.
I think the fact that those who have done their own testing have posted
their findings in various forums constitutes those tests as having been
'published'. I hope people share the testimonies found here with others
who 'make issue' of this subject. But then, as I stated in another
reply.., "to each their own"! (Note also that I've never seen an
'official' manual for 'good programming practices'<g>)
testimony of peoples findings (ergo details/results of their tests).
Most of my inspiration to test came from revered members of the VB/VBA
forums and so I did my own tests to see for myself. Up until one has
hard evidence of what's going on under the hood when we let use of
implicity creep into our programming discipline, it is really an eye
opener to 'self-discover' that the assertions of others are not really
'opinions' or 'speculations' at all. What I find more unfortunate is
that it's harder to find 'official' documentation. Thankfully, testing
is easily enough done without elaborate procedures to see the results.
I think the fact that those who have done their own testing have posted
their findings in various forums constitutes those tests as having been
'published'. I hope people share the testimonies found here with others
who 'make issue' of this subject. But then, as I stated in another
reply.., "to each their own"! (Note also that I've never seen an
'official' manual for 'good programming practices'<g>)
Mayayana
May 1, 2012, 11:53:17 PM5/1/12
to
So far I haven't had many ideas about how to test
this, but I have found some interesting things:
WScript.sleep 3000
MsgBox "1"
Test3
WScript.sleep 5000
MsgBox "3"
Sub Test1()
Dim Obj
Set Obj = CreateObject("jsShell.Ops")
WScript.sleep 5000
MsgBox "2"
Set Obj = Nothing
End Sub
Sub Test2()
Dim Obj, i
Set Obj = CreateObject("Scripting.Dictionary")
For i = 1 to 100000
Obj.add "key" & CStr(i), "item1"
Next
WScript.sleep 5000
MsgBox "2"
Set Obj = Nothing
End Sub
Sub Test3()
Dim Obj, i, i2, A1()
ReDim A1(100)
For i2 = 0 to 100
Set Obj = CreateObject("Scripting.Dictionary")
For i = 1 to 10000
Obj.add "key" & CStr(i), "item1"
Next
Set A1(i2) = Obj
Next
WScript.sleep 5000
MsgBox "2"
End Sub
With test2 and test3 subs I'm creating Dictionaries.
test2 creates 1 big Dictionary. test3 creates 100 and
puts them into an array. In both cases, the memory
is released at the end of the sub. In test1 I'm creating
an object from one of my own DLLs. The memory there
is not released until the end of the script. *In both cases,
whether or not I set to Nothing had no effect.* But
whether or not resources were released when the sub
ended varied.
When the Dictionary object variable was declared globally
it worked as expected: Setting to Nothing in the sub
released the memory, but if I didn't set to Nothing the
memory was held until script end.
this, but I have found some interesting things:
WScript.sleep 3000
MsgBox "1"
Test3
WScript.sleep 5000
MsgBox "3"
Sub Test1()
Dim Obj
Set Obj = CreateObject("jsShell.Ops")
WScript.sleep 5000
MsgBox "2"
Set Obj = Nothing
End Sub
Sub Test2()
Dim Obj, i
Set Obj = CreateObject("Scripting.Dictionary")
For i = 1 to 100000
Obj.add "key" & CStr(i), "item1"
Next
WScript.sleep 5000
MsgBox "2"
Set Obj = Nothing
End Sub
Sub Test3()
Dim Obj, i, i2, A1()
ReDim A1(100)
For i2 = 0 to 100
Set Obj = CreateObject("Scripting.Dictionary")
For i = 1 to 10000
Obj.add "key" & CStr(i), "item1"
Next
Set A1(i2) = Obj
Next
WScript.sleep 5000
MsgBox "2"
End Sub
With test2 and test3 subs I'm creating Dictionaries.
test2 creates 1 big Dictionary. test3 creates 100 and
puts them into an array. In both cases, the memory
is released at the end of the sub. In test1 I'm creating
an object from one of my own DLLs. The memory there
is not released until the end of the script. *In both cases,
whether or not I set to Nothing had no effect.* But
whether or not resources were released when the sub
ended varied.
When the Dictionary object variable was declared globally
it worked as expected: Setting to Nothing in the sub
released the memory, but if I didn't set to Nothing the
memory was held until script end.
Mayayana
May 2, 2012, 1:41:51 PM5/2/12
to
Here's another one that doesn't fit with either view:
WScript.sleep 5000
MsgBox "1"
Test2
MsgBox "2"
WScript.sleep 5000
MsgBox "3"
Sub Test2()
Dim ShAp, Wins
Set ShAp = CreateObject("Shell.Application")
WScript.sleep 3000
Set Wins = ShAp.Windows
WScript.sleep 3000
Set Wins = Nothing
Set ShAp = Nothing
End Sub
The memory used stays until the end of the script,
regardless of whether the objects are set to Nothing.
It seems that any object outside of the WSH runtime
itself is not handled properly. (Not released when a sub
ends, even though it's gone out of scope.)
For this test I used Process Explorer. I also tried
adding some code at the end of the sub, to make sure
that the Sleep wasn't preventing me from seeing
memory released.
Of course, none of this rules out the idea of setting
to Nothing within a sub. It only means that in some
typical, simple tests it has no effect.
WScript.sleep 5000
MsgBox "1"
Test2
MsgBox "2"
WScript.sleep 5000
MsgBox "3"
Sub Test2()
Dim ShAp, Wins
Set ShAp = CreateObject("Shell.Application")
WScript.sleep 3000
Set Wins = ShAp.Windows
WScript.sleep 3000
Set Wins = Nothing
Set ShAp = Nothing
End Sub
The memory used stays until the end of the script,
regardless of whether the objects are set to Nothing.
It seems that any object outside of the WSH runtime
itself is not handled properly. (Not released when a sub
ends, even though it's gone out of scope.)
For this test I used Process Explorer. I also tried
adding some code at the end of the sub, to make sure
that the Sleep wasn't preventing me from seeing
memory released.
Of course, none of this rules out the idea of setting
to Nothing within a sub. It only means that in some
typical, simple tests it has no effect.
Todd Vargo
May 2, 2012, 6:02:25 PM5/2/12
to
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
Set fso = Nothing
MsgBox "IsObject(fso)=" & IsObject(fso)
Same result here.
Dim d
Set d = CreateObject("Scripting.Dictionary")
Set d = Nothing
MsgBox "IsObject(d)=" & IsObject(d)
These results lead me to believe that setting an object to nothing does
not work at all. ISTM, all objects are outside the WSH runtime otherwise
they would be intrinsic/reserved keywords.
Setting the object variable to "" or Empty seems to release the object.
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
Set fso = Nothing
fso = "" 'or you can use Empty
MsgBox "IsObject(fso)=" & IsObject(fso)
Maybe this will work in your tests.
Mayayana
May 2, 2012, 10:54:05 PM5/2/12
to
Your samples seem strange but actually that's the way
IsObject is defined. It tests whether the variable is of
type object. You have to test for Nothing to see whether
it's a valid object:
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
Set fso = Nothing
If fso is Nothing Then
MsgBox "nothing"
Else
MsgBox "object"
End If
As near as I've been able to tell so far, libraries seem to
be loaded for the life of the script. One can release data
created and one can release objects, but in watching the
memory usage it seems to me that the memory used in
loading a library is not released no matter what. I guess
the reason that memory used by a Dictionary is completely
released is because the memory used to load scrrun.dll was
part of the script startup.
I tried creation of Shell.Application 3 times, inside a sub, and
accessed the Windows collection each time. The memory
usage goes up and down each time, but never returns to base
level and doesn't triple. In other words, once it's created that
memory is never released. But the memory used by the Windows
collection gets released each time. And the memory used by
Shell.App does not increase with subsequent created instances.
(Which makes sense. A loaded library will require notable
memory, but an inactive instance of an object only requires a
few bytes.)
The implication seems to be that there's no advantage to
releasing an extra library/component during the script. One
might just as well create them at script startup and leave them
live.
There is one aspect, though, that I find hard to test. With
Process Explorer I can test memory use until the WSH process
quits, but with changes in Windows RAM usage it's not easy
to confirm whether all memory used by WSH is always released
at the end of the script. On the other hand, if setting to Nothing
won't unload a library from the process memory, then there would
be no way to do anything about a memory leak anyway.
IsObject is defined. It tests whether the variable is of
type object. You have to test for Nothing to see whether
it's a valid object:
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
Set fso = Nothing
MsgBox "nothing"
Else
MsgBox "object"
End If
As near as I've been able to tell so far, libraries seem to
be loaded for the life of the script. One can release data
created and one can release objects, but in watching the
memory usage it seems to me that the memory used in
loading a library is not released no matter what. I guess
the reason that memory used by a Dictionary is completely
released is because the memory used to load scrrun.dll was
part of the script startup.
I tried creation of Shell.Application 3 times, inside a sub, and
accessed the Windows collection each time. The memory
usage goes up and down each time, but never returns to base
level and doesn't triple. In other words, once it's created that
memory is never released. But the memory used by the Windows
collection gets released each time. And the memory used by
Shell.App does not increase with subsequent created instances.
(Which makes sense. A loaded library will require notable
memory, but an inactive instance of an object only requires a
few bytes.)
The implication seems to be that there's no advantage to
releasing an extra library/component during the script. One
might just as well create them at script startup and leave them
live.
There is one aspect, though, that I find hard to test. With
Process Explorer I can test memory use until the WSH process
quits, but with changes in Windows RAM usage it's not easy
to confirm whether all memory used by WSH is always released
at the end of the script. On the other hand, if setting to Nothing
won't unload a library from the process memory, then there would
be no way to do anything about a memory leak anyway.
0 new messages