Does Debugger affect execution time?

You can find out for yourself by using some of the built-in timing functions. For example, you can StartMsTimer before running the code and then StopMsTimer after it is completed, or record Ticks before and after the function runs. I would time your code with the debugger enabled and disabled, and see if there is a reliable difference.

For more comprehensive analysis, see DisplayHelpTopic "Profiling Igor Procedures" (though the more basic functions might be more straightforward since what you're concerned about--the built-in error handling--might get used to some extent by the Profiling code.)

You can use DebuggerOptions to programmatically turn the debugger on/off and then benchmark.

Thanks for the responses. I had already incorporated Profiling and internal timing, but (being lazy) was hoping for a quick response based on someone's prior experience. In case others might be interested, using Thomas' suggestion I got the following results:

Profiling Debugger Time (sec, in largest code loop)

ON ON 614.6

ON OFF 608.0

OFF ON 592.8

OFF OFF 568.0

The lesson I draw is that profiling is useful for improving code, but should be applied sparingly otherwise.With no profiling, the Debugger does seem to add a small, but significant execution time increase. All times usually have a few second variation from trial to trial. (results with IP 8.03, Win10)

Thanks for the numbers. Is the code short enough to be posted here? Maybe we can still optimize it ;)?

Thomas, unfortunately I am not permitted to post the code (it is also large, and somewhat disorganized). I have performed extensive profiling, and A.G. has been of great assistance in applying MatrixOP to implicit-index wave assignments, and relocating factorable loop variables in the "high-value" Profile targets. The code structure is essentially sequential, so MultiThreading has not proved useful.