Re: Can 'MInifying' vbscript provide performance gain?
Tim Williams
IIRC at least for ASP, script files are only parsed once and the cached
intermediate code used after that point.
Most likely there's still something else which would give better results.
Tim.
"Jason" <Ja...@discussions.microsoft.com> wrote in message
news:CEB2EBF6-1540-46EA...@microsoft.com...
> Can removing all comments, blank lines, tabs etc from vbscript code
> provide
> any performance boost? We are looking to tweak any performance we can get
> out
> of our app, I know it's a bit extreme of a move but is it viable?
>
> I have created a script to do this and it removes about 12mb from the file
> system footprint. Do you think that when the scripts are interpretted this
> could save some time?
>
>
Richard Mueller [MVP]
> Can removing all comments, blank lines, tabs etc from vbscript code
> provide
> any performance boost? We are looking to tweak any performance we can get
> out
> of our app, I know it's a bit extreme of a move but is it viable?
>
> I have created a script to do this and it removes about 12mb from the file
> system footprint. Do you think that when the scripts are interpretted this
> could save some time?
>
In principal, removing white space should make the script run faster, but I
doubt you could measure the difference. In my experience, the biggest hit to
performance is the number of binding operations to objects that are not
local. Binding to local objects, like wshShell or the Dictionary object, is
fast, but binding to objects in Active Directory is slow. That's why
retrieving information from AD with ADO is so efficient. You bind to a few
local objects, then retrieve lots of values in one operation. Doing the same
thing by binding to each AD object would be much slower.
I have found that using "Option Explicit" and declaring all variables seems
to improve performance. My theory is that the interpreter no longer needs to
guess about your intentions, or perhaps it saves preprocessing. This despite
the fact that the file becomes larger.
I always use lots of white space and comments. I indent structures like
If/End If, For Each/Next, and Do Until/Loop. I use long descriptive variable
names. I never use With blocks. I try to always make things explicit and not
assume defaults. I use Option Explicit and declare all variables. Sometimes
others rewrite my code to be much smaller, requiring much less typing. My
chatty version is invariably faster. My motto is that anything that saves
the coder typing is generally not a good idea. All of this is in addition to
the "chatty" code being much easier to understand, troubleshoot, and modify.
--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--
mayayana
in general is very slow. You can make things more
efficient by doing things like reducing object
references. (Reducing periods.)
For instance:
With window.event.srcElement
x = El.width
y = El.height
ID1 = El.ID
End With
should be faster than:
x = window.event.srcElement.width
y = window.event.srcElement.height
ID1 = window.event.srcElement.ID
Or you could also set a new variable to
srcElement and then work with that.
But the difference is not worth worrying
about except insofar as it helps to cultivate
good coding habits. Most of the operations
that script does are extremely inefficient
to begin with. And script is so far removed from
what's really going on that it's often not easy
to keep track of what's efficient.
If you need speed then use compiled code.
Jason
I am aware of the cache, but was unable to find more detail about that
intermediate code you mentioned. I figure at that point all includes are put
in line, but I was wondering if any other preprocessing (I guess you might
call that psuedo-compilation) had been done. Do you if this intermediate code
still has all the comments included?
There are definitly other options that would provide more benifit, we are
simply looking for any way to squeeze a little more performance out of our
aging system. We will be doing a full rewrite when a new technology is
selected but that is 1-2 years on the horizon.
THanks for the response.
-j
Jason
That should be useful.
We are not looking to avoid typing for the developers.
The minifcation of the codebase would be executed in production environments
only.
Because vbscript needs the new lines for each statement we can't minfiy as
extreme as you could with say Javascript. The result is that the code is
still pretty readable considering and we are willing to manually translate
our error line numbers between the full and minified versions if performance
can be gained on each ASP request.
In theory the minified code should run faster as the interpreter no longer
has to ignore these lines. That is if the code hasn't been modified other
than putting the includes in line when it is stored in the cache.
Jason
compiled language isn't an option at this time. We are still using MSCMS
2001. So we are on classic ASP with SQL2000 and that's just the way it is. :)
We should review our code to try to reduce object references, thanks for
that. :)
-J
mayayana
> compiled language isn't an option at this time. We are still using MSCMS
> 2001. So we are on classic ASP with SQL2000 and that's just the way it is.
:)
>
> We should review our code to try to reduce object references, thanks for
> that. :)
>
If "every little bit helps" you might try posting code
and see if someone has ideas to make it more efficient.
I can't imagine that reducing comments will matter, but
there might be some things that could be made more
efficient if you're doing things like working with a large
number of string concatenations, long do-loops, heavy
object usage, etc. For instance, if you write a script
to open a file and read it out, every step is very
inefficient, with the script needing to be first interpreted
by the script host, then the host has to load a COM
library, which then reads the file and performs data
conversion to return the text string. Etc. Yet all of
that happens instantly in human terms. What really slows
it down is if, say, there are a very large number of
operations done on the returned string. So there might
be room for improvement there. But what you're
talking about optimizing by cutting out comments is
just a miniscule part of that first set of operations that
were already "instant".
Tim Williams
"Appendix 3: ASP Caching
The ASP Template Cache stores templates: pre-compiled ASP pages in text
format (#includes have been evaluated, and so on). Its size is governed
by the AspScriptFileCacheSize setting in the metabase, which defaults to
250. The ASP Script Engine Cache holds ASP templates that have been
compiled into byte code. Its size is governed by the
AspScriptEngineCacheMax setting in the metabase, which defaults to 125.
The relationship between the two is that an ASP page is cached once in
the template cache, but it can appear many times in the script engine
cache if it is being executed on many threads simultaneously. A site
with a lot of memory and a lot of distinct ASP pages that get hit often
will probably want to increase AspScriptFileCacheSize (monitor ASP
counters with System Monitor to diagnose). There is much less need to
increase AspScriptEngineCacheMax; the main reason would be that the
defaults are inadequate for machines with 8 or more processors.
AspScriptEngineCacheMax should have a metabase value that is equal to or
greater than the number of CPUs plus one, multiplied by
AspProcessorThreadMax. AspProcessorThreadMax defaults to 25.
Every process that hosts ASP will have its own ASP Template and Script
Engine Caches. By default that is just one process because ASP
applications run at medium isolation in the pooled Dllhost process.
When ASP gets a request for a page, it checks the ASP Template Cache
first. If there's an instance of that page cached there, the request is
forwarded to the Script Engine Cache. If the requested page is not in
the Template Cache, it is compiled into a template and forwarded to the
ASP Script Engine Cache. If an instance of the page is cached in the
Script Engine Cache and it is ready to run, that engine is run. Failing
that, if there is an instance of the page that is already executing, ASP
clones that running engine and executes the clone. This avoids the cost
of re-parsing the template into byte code. If there is no script engine
associated with the page, ASP takes the precompiled template from the
ASP Template Cache, creates a new script engine and has it compile the
template into byte code, and then executes it. When a page finishes
executing, the script engine is put at the head of the free list. If the
free list has grown larger than AspScriptEngineCacheMax, the
least-recently used script engine is destroyed. A hit in the script
engine cache means that ASP can avoid recompiling the template into byte
code.
Good Luck,
Michael D. Kersey
"
Tim
"Jason" <Ja...@discussions.microsoft.com> wrote in message
news:F7D69E67-83B6-4224...@microsoft.com...
Jason
on the contents of those cache's. From the description, minification would
have no effect on requests to the ASPScriptEngineCache because it is already
byte code.
Jason
Billy Zane
>...
> Because vbscript needs the new lines for each statement we can't minfiy as
> extreme as you could with say Javascript.
Not that I think you will see a speed increase, but you can use a colon (:)
in VBScript to separate statements.
--
BZ