Ten+ Ways to Make Mentor Run Faster

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.

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.