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).

Hardware

1. 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.

2. 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).

3. 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

1. Macro performance is not affected by the number of macros you create.

2. Macro performance is not affected by the length of a definition's name.

3. 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.

4. Keep the macros as short as possible (particularly the line count).

5. 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.

6. 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.

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

8. 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.

9. 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.

10. You can use "#define+" & "#evaluate+" instead of #undef.

11. 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.

12. 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>
    #}
    

#AutoTag Performance

1. Unlike macros, the more autotags you have defined the slower it will be to tag each line.

2. Replacing autotags (defined with #AutoTag) is a relatively slow operation. Only use if no other way and for as few lines as possible.

3. 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.

#AsIs Performance

1. Unlike macros, the more changes you have defined the slower it will be to tag each line.

2. 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.

Other Performance Hints

1. 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...

2. 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.

3. 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.

4. Maybe increasing your hard disk cache size could improve things. You might wish to try the /Inc2Cache switch.

5. You might wish to try PPWSORT.H macros rather than ArraySort().

6. 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)!

email me  any feedback, additional information or corrections.
See this page online (look for updates)

PPWIZARD Manual

Sunday November 05 2017 at 10:00am