Ten+ Ways to Make Mentor Run Faster

There are two ways of measuring the speed of a tab run. The time ittakes to complete a project from start to finish, and the time it takesto complete an individual Mentor run. The following are divided roughlyinto those two groups.

Use a faster CPU. This is not a joke. For the most part Mentor runsare number crunching, and doubling your CPU speed will cut nearly allof your run times in half.

Although extra RAM will not increase processing speed, not havingenough will cause some Mentor runs to execute very slowly. Very largesort routines, for example, will run very slowly when not enough RAMis available. If a performance monitor (e.g. soo on MPE, top or xosviewin Unix) shows a lot of “swapping” then not enough RAM is almostcertainly the problem.

Check your runs for bad spec writing. The most common form of bad specwriting is using many instructions where one could have used less.If speed is a critical issue, look for places where the number ofindividual instructions can be reduced. Minimize the number of AND, OR,WITH, and IF instructions wherever possible. Keep in mind, however,that sometimes “bad” writing may have saved a great deal of human time, ormay make a run much easier to check.

When running on a network, having the data on the machine that is runningthe job is much faster than running with the data on a remote machine.Having Mentor on a remote machine, however, adds only a tiny bit ofoverhead.

Redirect your screen output to a file (Unix). This can allow your runto finish in 5-10% less time. If you need to know what is being sent tothe screen use a pager (more, less, pg) to look at file to which theoutput is being redirected.

Recode your banner specs into simple multi-punched data locations. Thisis most useful when your banner specs contain a great number of joiners(AND, OR, WITH, etc.).

If you need to interleave banners use store=* and then load and printinstead of tab=*. Do this by using >listdb with a template to make theload and print statements, and then sort the .dcl file into the orderyou need for the printed tables.

Using ASCII data vs. a .tr files can make a speed difference. An ASCIIfile that is nearly blank will read at about the same speed as one thatcontains data in every column. A sparsely answered .tr file will readfaster than one where most of the columns contain data.

It takes time to create the directory of a .tr file (this happenswhen you use the NUMCASES option). It takes more time to make a largedirectory than it does to make a small one. Make sure that you need thedirectory at all, and choose realistic settings for NUMCASES when itis used.

Use pound-sign rather than punch variableswhenever you are tabulating long lists of categories.

When creating variables for while loop counters, etc., using a datalocation instead of a table cell will run faster. This will howeverreduce the flexibility of the run, and may later lead to expendingmore human time.

When running independent stat testing, including i= on your stats= specwill make it so that Mentor will run much faster.

Put similar tasks together in your spec files. For example, ~defineall of your variables, build the tables, and then load and print them.This helps keep “code page” swapping and file i/o down to a minimum.

Run your jobs in the background using a .bat file, shell script, etc.On a job that’s big enough for time to be a concern there’s almostcertainly something else you could be doing while the job runs. If yourmachine is fast enough to be appropriate for running large jobs, youprobably can’t read the screen output anyway.If Mentor ends in error it always has a non-zero exit status thatcan be used for flow control. (The exit status is set to the number oferrors in the run.) The fact that you aren’t watching your job runshould not mean that you are out of touch with how it’s doing. On Unixmachines for example you can examine most of the files that Mentor iscreating while the job is still running.

Don’t use excessive core settings “just in case”. Although this onlyhas a moderate effect on your jobs runtime (i.e. it takes a littlelonger to start up), it will drag down the overall performance of themachine you are working on, or in some cases may even lock it up.

Make cleaning corrections with a spec file instead of interactively.Although this breaks the rule of not using lots of IF statements, ithas a very positive effect on overall job flow, and therefore savestime over the long haul. Cleaning error reports are easily modifiedto become a file of correction instructions. If your first correction
pass doesn’t fix all of the errors, you know exactly what was done toevery respondent and can add to or undo any part of it.

The >stop_watch command displays elapsed time for portions of a Mentorrun. If you have a Mentor run that seems to be taking an inordinateamount of time to run it may be due to a single portion of the run,which can be discovered with the help of >stop_watch.