PPWIZARD is a free preprocessor for HTML, REXX, Visual Basic or any text files.
\ -> Performance
While PPWIZARD is written in rexx a lot of work has gone into keeping
it fast.
It has a lot of features and I'll probably add more.
In general I have added these with no loss of performance
(in fact I've generally gained as I've rewritten parts to add
new functionality).
As PPWIZARD is so powerful you will be tempted to do some very
complex things, much like I have in writing the document you are now reading
in PPWIZARD macros.
This section aims to give you some hints as to what you can do to speed
up processing (if you need to).
- This may be obvious but PPWIZARD is generally CPU bound.
What this means is the speed of the CPU is directly proportional
with the time PPWIZARD takes.
Forget the benchmarks in your favorite magazine where they
show "real world" performance (look at video encoding benchmarks etc).
If your CPU is twice as fast PPWIZARD will take half the time.
The only exception to this is if you have insufficient RAM
(and there is no excuse of that these days)!
Do yourself a favor and use the fastest machine you can find/afford.
- For very large tasks or possibly where large databases are
involved PPWIZARD may be memory bound, in this case a faster
CPU will probably not make much difference.
To ensure you have enough RAM, let the task run for a while and
then look at the total committed versus total physical RAM as well
as the peak committed (use Task Manager under Windows).
- If your hard drive supports DMA access then make sure it is
turned on.
Of course a 7200 RPM drive with a large cache will be faster to
access than a 5200 RPM with small cache...
- Macro performance is not affected by the number of macros you create.
- Macro performance is not affected by the length of a
definition's name.
- The #evaluate & #if commands
are relatively slow.
If you have large numbers of these in your source then
where possible use the #define or
#RexxVar command in place of "#evaluate".
The #if [] form is very quick and should
be used where possible.
Better yet for complex logic consider using straight
rexx code, possibly defined using
#DefineRexx, this allows you to use rexx's
"select" etc and rapidly perform complex logic.
- Keep the macros as short as possible (particularly the line count).
- Don't include conditional logic where possible.
For example if you know at macro definition time that you
will never follow a certain path then don't include it (that is
conditionally generate the macro once).
Not only will the line count decrease but a #if
command is one of the slower ones.
Another benefit is that its easier to watch what is going
on when debug mode is on.
- In a similar vein to the previous point, if you have to pass a
parameter to a macro to conditionally execute a certain path, then
it would be better to create multiple variations of the macro and
drop the parameter and conditional generation code.
- To make code easier to understand I usually do one rexx task per
#evaluate, however as an evaluate is slow you could
bunch a number of rexx commands in one #evaluate
command (at least in any of your high use macros).
The #DefineRexx command can be used to define a
whole series of rexx statements in an easy to read/understand way.
- You have the choice of storing information in a macro or
rexx variable. Look at your main uses for the variable and
decide which is best for each situation.
If you are doing heaps of rexx manipulations or tests
(#if etc)
then it would normally be better as a rexx variable.
- You can save steps in a macro by using
"<??Variable>" to get access to a rexx
variable without first having to get a copy with
#evaluate.
- You can use "#define+" &
"#evaluate+" instead of
#undef.
- For simple text macros you might want to consider using rexx
variables.
Depending on how you use the information using rexx
variables can be much faster, for example in a #if
or #evaluate statement you can remove the need
for the substitution syntax and use the value directly.
Where you do need to specify substitution use the
<??Variable> syntax.
- A lot of smaller values is better than one really huge
one especially if lots of substitutions are required.
You might call some rexx code to generate one or more lines,
if this output is likely to be quite large then it would be better
to create it in a rexx array similar to:
;--- A process which generates "lines" (into rexx array) ---
#NextId
#DefineRexx ''
Vb.1 = "line1"
Vb.2 = "line2"
Vb.0 = 2
#DefineRexx
;--- A process which uses them ---
#{ for @@l = 1 to Vb.0
<??Vb.@@l>
#}
- Unlike macros, the more autotags you have defined the slower
it will be to tag each line.
- Replacing autotags (defined with #AutoTag) is
a relatively slow operation.
Only use if no other way and for as few lines as possible.
- To temporarily reduce your autotag count (remove ones you don't need) you
can use the #AutoTagState to hide current definitions
before creating your own command.
Making good use of named states will simplify this process.
- Unlike macros, the more changes you have defined the slower
it will be to tag each line.
- There is inbuilt optimization for single character "from" text, if
possible group these together.
This allows the
BulkChar2String()
routine to be used to greater effect.
Tagging must take place in the order you
specify so PPWIZARD does not reorder the items to improve
performance.
- Color processing (see the /Color switch) will
slow down processing (possibly significantly).
How much it slows down and matters is largely dependent on the
number of files you are processing (a half second task taking 1 second
is probably OK but
a 30 second process taking 60 seconds may not be...
- Under OS/2 you have multiple choices as to which rexx interpreter
you can use (DOS has 2 as well).
There is the REGINA version as well as traditional rexx (as
exists after OS/2 install) or Object Orientated Rexx.
If you find things a bit slow it is probably worth
your while experimenting.
Different interpreters will do some things better than others.
You really need to time your particular situation.
- File performance would normally not effect ppwizard too much but
is worth checking.
For common headers etc it may be better if they were not on a
network drive.
Better yet a RAM disk would be good.
- Maybe increasing your hard disk cache size could improve things.
You might wish to try the /Inc2Cache switch.
- You might wish to try PPWSORT.H macros rather
than ArraySort().
- PPWIZARD is optimised for fast execution with debug turned off,
and in fact may perform extra work when debug is on (on
the assumption that execution time is not an issue).
So for high performance turn debug off (or only have on for sections
really required)!
PPWIZARD Manual

Saturday May 28 2022 at 2:55pm