viewpoint-particle

Author Topic: Startup performance  (Read 9578 times)

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Startup performance
« on: March 14, 2014, 03:53:22 pm »
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

  • Tech Support
  • *****
  • Posts: 3453
    • WinBatch
Re: Startup performance
« Reply #1 on: March 15, 2014, 09:43:33 am »
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. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #2 on: March 16, 2014, 08:57:26 am »
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

  • Tech Support
  • *****
  • Posts: 3453
    • WinBatch
Re: Startup performance
« Reply #3 on: March 17, 2014, 08:09:46 am »
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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

  • Tech Support
  • *****
  • Posts: 3453
    • WinBatch
Re: Startup performance
« Reply #4 on: March 18, 2014, 07:02:16 am »
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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #5 on: July 07, 2014, 08:46:45 am »
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

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #6 on: July 07, 2014, 08:49:19 am »
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

  • Pundit
  • *****
  • Posts: 1164
Re: Startup performance
« Reply #7 on: July 07, 2014, 10:51:27 am »
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

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #8 on: July 07, 2014, 10:58:29 am »
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

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: Startup performance
« Reply #9 on: July 07, 2014, 10:58:51 am »
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.
Deana F.
Technical Support
Wilson WindowWare Inc.

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #10 on: July 07, 2014, 11:02:37 am »
'bout the same.

Deana

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: Startup performance
« Reply #11 on: July 07, 2014, 11:05:02 am »
Deana F.
Technical Support
Wilson WindowWare Inc.

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #12 on: July 07, 2014, 11:08:21 am »
Well, considering that the debugTrace starts at line zero... there's nothing being logged in the time prior to that.

Deana

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: Startup performance
« Reply #13 on: July 07, 2014, 11:17:49 am »
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
Deana F.
Technical Support
Wilson WindowWare Inc.

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #14 on: July 07, 2014, 11:23:28 am »
Well, here's that:


Quote
************************************************************

*** 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

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: Startup performance
« Reply #15 on: July 07, 2014, 11:31:54 am »
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.



Deana F.
Technical Support
Wilson WindowWare Inc.

stevengraff

  • Sr. Member
  • ****
  • Posts: 271
Re: Startup performance
« Reply #16 on: July 07, 2014, 11:51:11 am »
Well :), that sounds definitive!

Deana

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: Startup performance
« Reply #17 on: July 07, 2014, 12:00:22 pm »
Well :), that sounds definitive!
Wasn't intended as definitive, however might explain a possible delay.
Deana F.
Technical Support
Wilson WindowWare Inc.

DAG_P6

  • Full Member
  • ***
  • Posts: 184
  • WinBatch rocks, and so does Wilson WindowWare!
    • WizardWrx
Re: Startup performance
« Reply #18 on: July 08, 2014, 07:21:06 pm »
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.
David A. Gray
You are more important than any technology.