Vista - Slow string

Hello,

I wrote a cli script to track usage in a database. The script runs fine
except if you execute it without any options it returns the command syntax
like it should but it is VERY SLOW. It takes about 4 seconds to output it to
the screen. I can open the database, add a new record, open the log file and
add a new log entry in about 1 second... I know that using a lot of &s can
slow it down but how else do I build the string? Here is the code in
question:

Thanks,
Ernst

strQuote = Chr(34)
strTab = Chr(9)
strNext = vbCr & vbLf

AbsPathINI = AbsPath & Left(WScript.ScriptName,Len(WScript.ScriptName)-3) &
"ini"

strSyntax = " Syntax for the Script is as follows:" & strNext & strNext _
& " " & WScript.ScriptName & strTab & "/t:{Image Tag} [/a /s:{Tag
Description} | /r | /R] " & strNext _
& strTab & strTab & "[/i:{INI File}] [/c:{Count}] [/d:{Last Access
Date}]" & strNext _
& strTab & strTab & "[/l:{Log File}]" & strNext & strNext _
& " Update mode will be used unless one of the 'Mode Switches' (/a,
/r, or /R)" & strNext _
& " is used. Combining the 'Mode Switches' will result in the last
one" & strNext _
& " provided being used." & strNext & strNext _
& " Options:" & strNext & strNext _
& " /a" & strTab & strTab & strTab & " - Add a new tag. Must
be combined with the" & strNext _
& strTab & strTab & strTab & " '/s' switch" & strNext _
& " /r" & strTab & strTab & strTab & " - To retrieve tag data
for a specific tag." & strNext _
& strTab & strTab & strTab & " Used with the '/t' switch."
& strNext _
& " /R" & strTab & strTab & strTab & " - Retrieve ALL tag
data. No other switches " & strNext _
& strTab & strTab & strTab & " are required." & strNext _
& " /t:{Image Tag}" & strTab & strTab & " - Tag to be updated /
added to the " & strNext _
& strTab & strTab & strTab & " database. This switch is
required." & strNext _
& " /c:{Count}" & strTab & strTab & " - User provided tag
count. Used to reset " & strNext _
& strTab & strTab & strTab & " or force the count to a
specific value." & strNext _
& " /d:{Last Access Date}" & strTab & " - User provided 'Last
Accessed Date.' The " & strNext _
& strTab & strTab & strTab & " default is today's date." &
strNext _
& " /i:{INI file}" & strTab & strTab & " - INI file with
relative path. The default is" & strNext _
& strTab & strTab & strTab & " " &
Left(WScript.ScriptName,Len(WScript.ScriptName)-3) & "ini " _
& "in the current directory." &
strNext _
& " /l:{Log File}" & strTab & strTab & " - Log file with
relative path. This " & strNext _
& strTab & strTab & strTab & " switch overrides settings in
the INI " & strNext _
& strTab & strTab & strTab & " file. Default output is to
the console." & strNext _
& " /s:{Tag Description}" & strTab & " - Description of tag.
This switch is " & strNext _
& strTab & strTab & strTab & " required with the '/a'
switch." & strNext & strNext _
& " Make sure to enclose string values in quotes."


' Check for 0 arguments and return syntax if true
If WScript.Arguments.Count = 0 Then
' Syntax for script
WScript.echo strSyntax
WScript.Quit
End If

That's not the code in question. It works instantly for me.
All it's doing is building a string and showing a msgbox.
So why would you assume that's the problem?

String concatenation is slow. If you had to construct that
same string 10,000 times it might be worth putting the
substrings into an array and Join-ing them with vbCrLf, but the
amount of concatenation you're doing is not significant.
toandcan&(/a,lastMustdata

hmm... Yes with Wscript it works a lot faster than Cscript. being its a CLI
utility i have it run with cscript. Is there a difference in execution time
between the two? And is a few second delay exceptable under normal
circumstances?

Thanks again,
Ernst.


"mayayana" wrote:

I can confirm what Mayayana said; it doesn't really matter - the code is
actually quite fast, Ernst. : )
Some numbered questions below, and also a couple of comments on the general
problem and suggestions for things you _might_ want to do to make your code
simpler or run faster.

(1) Execution time and questions
I see virtually no difference in execution time for the code you posted when
using cscript versus using wscript; to confirm, I bracketed the code with an
initial
t0 = timer
and, in the check for arguments, the following line
WScript.Echo (timer - t0)

This shows about 10-20 ms delay maximum, and sometimes "0". This is actually
a bogus value, since the limits of resolution are about 20 ms - so all that
establishes is that it's "really, really fast".

NOTE - this tells us about the time taken from when the script
_begins_to_execute_ to when it is ready to exit. So other issues, such as
the launch method, aren't considered. An important question here is: Are you
actually entering the script name into a console window (possibly with
cscript explicitly used in a command)? Or are you simply performing
point-and-click startup - and if that is the case, are you seeing most of
the initial delay happening _before_ the console window appears?

If it's the latter, the lag is occurring in the console window spawning,
which isn't due to WSH itself. I suspect that this may be the real issue.
The real workaround for this is to simply run it from a console window.

(2) Cleaner (and faster) console script execution with a wrapper
Another startup technique that ensures the host is cscript, prevents input
pipeline breaking, and coincidentally shaves off a tiny bit of startup time
is to use a wrapper .cmd script the same way that Perl and a few other
console script environments do. Here's all you need to do. In the same
folder as the VBScript, put in a .cmd file with the same base name and one
line of content. If your script is called AddData.vbs, you would use the
name AddData.cmd (or AddData.bat) and it would contain the line

@cscript //Nologo %~dpn0.vbs %*

You can use the exact same line for every wrapper script - and that includes
wsf and js scripts; all you need to do is change the final "vbs" to "wsf" or
"js" as appropriate.

(3) String building - nonlinear, but not enough to matter here
If you build a large string by small concatenations, the performance
degrades geometrically - so does array resizing, because they both use the
same nasty technique inherited from VB1 of copying the entire data structure
to a new structure with the added element. So adding 1 character to a string
with 10000 characters takes 10,000 times as long as adding it to a string
with only 1 character. However, even this is pretty fast and only matters if
you're doing it thousands of times. I don't think your problem is your
stringbuilding technique.

(4) Speeding up startup (and execution) internally
This won't matter a great deal in most cases, but if you use Option Explicit
(without On Error Resume Next following it, of course) you do get faster
dynamic compilation and execution. This is because identifier lookup can
happen much more rapidly.

(5) WSFs for help display
Based on what you've done here, I suspect you would LOVE using a WSF file
structure instead. You can include string blocks as resources, but even
better you can provide a runtime block of help text and a simple list of
arguments. The WSF will actually create the correctly-formatted help string
(including marking for whether an item is mandatory or optional,
boolean/simple/string values, and even the WSF's own name).
The critical thing is that if you do want to provide an explanatory
paragraph or two, you just write it in the correct block as plain text with
no need for special ways to write tabs/quotes/etc.

(6) VBScript values
Not relevant if you switch to a WSF, but you can do a couple of the symbols
more easily. There's a built-in vbTab and a CR+LF combo is either vbCrLf or
vbNewLine.



"Ernst Guckel" <ErnstGuckel@xxxxxx> wrote in message
news:58604BF4-1835-4EE7-B936-66905915E59D@xxxxxx

Ernst Guckel schrieb:[...]
I used the script with cscript.exe and got the output 'immediately' (in any
case as fast as with wscript.exe).Especially as the concatenation is done regardless of whether
the program is started with zero arguments or not.I agree with that. But putting the lines (with spaces instead of Tabs)
into an array and joining them with vbCrLf would simplify the script
considerably.
[...]
If that is true, then one of the lines

WScript.echo strSyntax
WScript.Quit

(or both) must be the cause of the delay - or you didn't show us the
real code.