Startup performance

[stevengraff]

OK, it's not enough that my WinBatch app performs minor miracles for its target market... now they want fast miracles. :)

Does using Large compiled exe's slow things down much, after the initial dll extraction? Any tools that will tell me which statements are the big offenders prior to the first dialog smiling hello?

[td]

The only execution time difference between large and small exes is the extraction.  You can use the DebugTrace function to obtain the timings for each statement in the output trace file.

The most common time burners in WinBatch scripts are the While, For, and Foreach loops when they have a significant numbers of iterations.  This is one reason why we have added several functions for performing array operation that could also be accomplished via loops in a script.  Internal functions are many magnitudes faster than script loop structures. 

[stevengraff]

Does the extraction only happen once? Does the script check first to see whether the dlls are already there, and then skip extraction if they are? (in which case the performance hit would be roughly once per lifetime)

[td]

A compiled exe will check for the existence of the correct version of the WIL interpreter DLL and skip extraction when it already exists.  IIRC, all other files are extracted without checking for an existing file.

The extraction process is fairly quick on most modern systems.  The biggest hit may simple be the larger size of the file. But on modern systems there are so many variables it is hard to judge the influence file size might have on load time.

On Windows 7 exes that are marked for elevation can take significantly longer to load the first time they are used than a "asInvoker" equivalent.  Here again this can vary quite a bit form system to system and is not much of an issue on Windows 8.

[td]

IIRC, all other files are extracted without checking for an existing file.

The above statement is not incorrect.  As is the case with the WIL interpreter dll, the compiled script will not extract any extender that it can identify as already existing on the system.

My apologies if I mislead anyone.

[stevengraff]

The only execution time difference between large and small exes is the extraction.  You can use the DebugTrace function to obtain the timings for each statement in the output trace file.

The most common time burners in WinBatch scripts are the While, For, and Foreach loops when they have a significant numbers of iterations.  This is one reason why we have added several functions for performing array operation that could also be accomplished via loops in a script.  Internal functions are many magnitudes faster than script loop structures.

Presently I send an SQL query and get the result back as a list, about 200 records, 12 fields each. Then I use a "while" loop to "condition" the data for further display and manipulation.

You're saying this operation might be more efficient loading the return data into an array?

Got any examples?

[stevengraff]

In checking the timing of various ops, I tried placing a message command as the first line of my script. It takes 2 - 5 seconds for the message to appear after launch. Anything to be done about that other than buying a newer faster computer? Or using a ramdisk?

[stanl]

Anything to be done about that other than buying a newer faster computer? Or using a ramdisk?

If you are using ADO for your connection and SQL commands, there are parameters you can tweak to improve performance. Setting a static forward-only cursor is perhaps the quickest unless you need to return data or are performing updates or batch updates.

Often the Connection.Execute() is faster for SELECTS in that it creates a recordset by default. Or, using the Command Object is sometimes faster... it all really depends.

Then there is the datasource itself, is it indexed or otherwise optimized....

If you have already thought about and practiced the above, then perhaps hardware or memory is the solution.
 

[stevengraff]

It's helpful, for sure, but n/a to the specific question, which is why 2 to 5 seconds get burned up just waiting for the script to get to line 1.

[Deana]

In checking the timing of various ops, I tried placing a message command as the first line of my script. It takes 2 - 5 seconds for the message to appear after launch. Anything to be done about that other than buying a newer faster computer? Or using a ramdisk?

How was the script manifested? If running as a .wbt file the manifest requests elevation by default. Try using AsInvoker manifest instead. Simply give the script the file extension .wbt_if and test that.

[stevengraff]

'bout the same.

[Deana]

'bout the same.

DebugTrace output?

[stevengraff]

Well, considering that the debugTrace starts at line zero... there's nothing being logged in the time prior to that.

[Deana]

Well, considering that the debugTrace starts at line zero... there's nothing being logged in the time prior to that.

Contains details including platform, version and manifest settings. Just wanted to confirm the AsInvoker manifest setting was actually getting used.

;test.wbt_if
DebugTrace(@on,DirScript():'trace.txt')
level = UacManifestSettings( 1 )
Message( "Manifest Requested Execution Level", level )
Exit

[stevengraff]

Well, here's that:

************************************************************

*** Debug Initialized ***

==============================
Mon 7/7/2014 2:22:07 PM
WinBatch 32 2008B
WIL DLL 6.08bhb
C:\code\GoldSMS\GoldSMS.wil
Windows platform: NT, version: 6.1, build: 7601 (Service Pack 1)
ErrorMode: @CANCEL
==============================

level = UacManifestSettings( 1 )
(0) VALUE STRING => "highestAvailable"

Message( "Manifest Requested Execution Level", level )
(1888) VALUE INT => 1

Exit
(1888) VALUE INT => 0

--- Normal termination ---

;;;END OF JOB;;;

[Deana]

The DebugTrace indicates you are running WinBatch 2008B on Windows 7. That version is not supported on Windows 7.

Windows 7 support wasn't added to WinBatch until 2009C. http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch+!WinBatch~Platform~Support.txt

I tested the following code using Debugtrace, WinBatch 2014A, on my Windows 7 system and the first statement (uacManifest settings) completed at 93 milliseconds. Quite fast.

[stevengraff]

Well :), that sounds definitive!

[Deana]

Well :), that sounds definitive!

Wasn't intended as definitive, however might explain a possible delay.

[DAG_P6]

Support issues aside, I have one very ancient compiled script, which runs against a 2005 interpreter, and it runs without issues on Windows 7. We've never had an issue with it, it's still at version 1.0, and I don't even know where the source code went. It just works.