How to Optimize Winbatch

Keywords:    fast speed app run WinBatch yield wbt  IntControl(43, p1, 0, 0, 0) optimization exclusive

Winbatch Optimization:

Shorter variable names won't make a difference. Unless used carefully, dropping variables will not make a noticeable difference in speed.
If you're using a very large number of variables, there *might* be a slight advantage to declaring the most-used ones early in the script, and dropping variables no longer being used couldn't hurt.
We optimize Goto's and Gosub's, so there is no time spent searching for the labels. I can't think offhand of any generic structural optimizations you could make.
Obviously using binary file read operations could make a dramatic improvement, but we have recently optimized normal file reads as well (in the 99 version of Winbatch).

There are various tricks have made some files execute much much faster. (Mostly using BinaryOperations instead of File functions.

General Optimization Hints:

There are various ways to optimize code.

The trick is to find the slow spots (DebugTrace can help) and optimize those. Someplace for each line of the DebugTrace file is a number in parenthesis. This number is a timestamp (milliseconds?) of what time the statement was executed.

With some poking around you can figure out where the big time delays are.

Basic rule of thumb 90% of the time is spent in 10% of the code. Optimize that 10% and don't worry about trying to squeeze time out of the rest.

Hints that I would not like to let people know about....

WinBatch, compiler or not, is kind of an obscure hybrid of an Interpreter and a compiler, being somewhat closer to an interpreter.

Most of the time is spend figuring out what the statements are telling it to do. Very little time is actually spent doing the intended task. Tests have shown that, in general, nothing affects executing time so much as simply the number of lines of code. Grabbing the next line and figuring out what is is telling WinBatch to do takes all the time. It seems to not matter quite so much how much stuff is on the line.

Therefore...

Reducing the number of lines of code executed will improve the speed. Although, Doubling and tripling up on functions in a single line is faster, but harder to debug.
Goto's are faster than structures.
Short variable names run faster.
Initialize often-used variables at the top of your script. Just
xx=0
where xx is the index for a for loop can help.
It used to be that not indenting the code helped, and it used to be that not commenting code helped, but I think that got fixed.
Making one line do everything instead of breaking it up helps speed, but trashes debugging.

Question on Slowdowns of Winbatch moving from WB2000B to WB2000C:

Recently I tried to upgrade to the latest version of WinBatch 2000, the "C" version, from what we were using, WinBatch 2000 version "B". However regardless of how I compiled the WB EXE (small or large, "B" version or "C" of the WinBatch 2000 compiler), whenever I placed the "C" version of the WBDBV32I.DLL into the C:\WINDOWS directory with the compiled EXE program, the WB EXE would always run four to five times slower the first time it was run (i.e., after the computer was powered on or restarted).

On consecutive logons (after logging off and not restarting or rebooting the computer), the WB EXE would always run at "normal" speed, regardless of which version of WBDBV34I.DLL was in the C:\WINDOWS directory. This was not a problem for us with the "B" version of the WBDBV32I.DLL (to which we have now restored to all such computers that use this system), only the "C" version. This leads us to believe that there is a significant problem with the "C" version of the WBDBV32I.DLL.

Answer:

We have made some significant changes between the 2000B and 2000C versions of Winbatch. We address this somewhat elliptically in the Fixes.txt file, when we say, "Changed the internal routine used to create delays (eg, to wait for a window to appear or a program to finish), so that during the delay the WIL Interpreter is now more responsive to window messages."

In general, by default Winbatch now gives much more processing time to whatever other applications are running. So, for example, if a screensaver is running, it can monopolize the processor and Winbatch will wait around for it to give back some processing time.

Try adding Exclusive(@on) to the top of your script, and see if that fixes it. This will make Winbatch alot stingier in terms of processor time. Then, if there are parts of your script where you don't want Winbatch to take so much, you can turn Exclusive(@off).

Question, RE: Runwait:

Using ver. 96M of Winbatch the RunWait command takes 30 seconds to load and begin execution. This is using a Win 95 100Mhz Pentium. When the command line is executed using the Run command in Win 95 there is no delay. Do you have any suggestions for speeding up the process?

Answer:

30 seconds is about 100X too excessive. It should take about 0.3 second at the most.

This indicates a severe configuration problem on the machine.

What version of Windows are you running? Are you using the 16 or 32 bit version of WinBatch.

The answer is likely to revolve around priority settings for the forground application. If it is set too high, it swipes all possible time away from the WinBatch script that is NOT running in forground or from the poor application trying to start up.

Question, RE: WB 5.1 and Outlook:

I am using a simple Winbatch Script to copy a file from one location to another, then run Microsoft Outlook, wait for it to close, then copy this file back to its original location. The problem that I am having is that while my WinBatch program is running, File Opens, Closes, Saves and URL launches slow down to the point that it takes 5 MINUTES to open. If I run Outlook without my program, it takes maybe 2 seconds. Something is happening with DDE I think. The reason I think this is that while this program is running I can not even click on a URL in Word 97 to launch a web page without it taking 5 MINUTES. Does anyone have an idea on how to fix this? I am using Winbatch and Compiler 5.1g.

Answer:

What version of WinBatch 5.1. 16 or 32 bit? What version of Windows?
It is known that 16 bit WinBatch multitasks badly on 32 bit Windows.
Is Citrix involved? This can affect speed.
Are you doing SendKeys? Look at:
```
	IntControl(43, p1, 0, 0, 0) (32-bit only)
```
and the Enable/disable "WaitForInputIdle" to change the idle setting.

Another Question, RE: FileReads and Speed:

I have a Winbatch program which reads a text file and parses out each word. In doing so, it does a lot of string handling including converting many unwanted characters to spaces then also check against about 100 common words (that I don't want indexed). The output from the routine is a flat file each record is _.

Granted this pushes the limits of string handling a bit, and granted WinBatch is an interpreted language, etc. But it's still _very_ slow to process. Is there any way to tell Win95 to speed up WinBatch, give it extra timeslices, or something like that???

Answer:

Well, as you've noticed, WinBatch is not designed for computationally intensive tasks. FileReads are slow in WinBatch. I suspect another problem is searching thru the list of the 100 works.

You might try this trick. At the top of the script set each word as a variable (except WinBatch reserved works like "end" "next" "for" "while" and assorted function names. Then it quick to check words.


osterich=1
feather=1
furry=1
handcuff=1
baseball=1

;Open file here

while 1

;read line

for each word on line 
 
    if IsDefined(word) then ...	 ; the word is in our list.  
				 ; avoiding search loop
next
endwhile

Also the Binary Operations are about 10 faster than the File Operations. You could read the file in in one swell foop, and then parse thru the binary buffer. If you are just interested in word counts, a flurry of BinaryStrCnt functions would provide that.

Instead of reading a line at a time and doing string manipulation to extract a word, you can change it around to read the file into a binary buffer and pull words out using BinaryIndex, (using the spaces between words as a delimiter and skipping ahead in the buffer the length of each word you find).

Article ID:   W13170

Filename:   Make WinBatch Faster.txt

File Created: 2003:02:12:13:35:18

Last Updated: 2003:02:12:13:35:18

Database Search

TechHome

How to Optimize Winbatch

Winbatch Optimization:

General Optimization Hints:

Question on Slowdowns of Winbatch moving from WB2000B to WB2000C:

Answer:

Question, RE: Runwait:

Answer:

Question, RE: WB 5.1 and Outlook:

Answer:

Another Question, RE: FileReads and Speed:

Answer: