Performance considerations

When IDF displays an area of memory, in either disassemble or dump format, the screen display is created dynamically, but a page-forward operation should occur at essentially the data transfer rate of the terminal.

If statement source is being displayed, the actual source text is obtained dynamically from the IDF Language extract data file. The extra overhead compared to pure disassembly is minimized by the design of the IDF Language Support.

Some delays may be noticed on heavily loaded systems, but these are generally in the nature of scheduling delays, where IDF is waiting its turn at the processor.

There is a general belief that using PER will cause a serious system-wide performance impact. When using CP PER this belief is probably well justified, since there is significant processing for any instruction that modifies storage, because CP performs a partial disassembly to determine where storage was modified. Since this processing is happening on the CP level it can seriously affect performance on a system-wide basis.

When IDF is used for a similar function, there should be no significant system-wide performance penalty above that imposed by any processor-bound application. Instead of disassembling instructions, CP needs only to report an interrupt to the virtual machine in which IDF is operating.

When the PATH option is OFF, the target program runs at what amounts to full speed between breakpoints. When the PATH option is ON, IDF causes an interrupt following every target program instruction.

Overhead per breakpoint varies in the approximate range of 300-500 IDF instructions per breakpoint. This includes prioritized breakpoint insertion, target activation, interrupt occurrence, event recognition, and saving the target program's state. The variation is as follows, with the first item shown being the least costly and the last item shown being the most costly:

PER OFF, PATH OFF
PER ON, PATH OFF
PER OFF, PATH ON
PER ON, PATH ON

Even though the PATH option can be relatively costly in terms of processor usage, it is extremely useful both for collecting code coverage information and for "back-tracking" by means of the HISTORY command.

Exit routines should also be used with some caution, since a REXX exec is executed each time a breakpoint event occurs.

When the list of subroutines to be skipped when single-stepping, statement stepping, or running with PATH or FASTPATH active is not empty there is more overhead on every "subroutine call instruction" (for example, BALR, BAL, BASSM) that is executed. There is a binary search of the list of subroutines to be skipped to determine if the subroutine being called is supposed to be skipped.