Parallel Search is a performance-enhancement option that makes use of multi-core systems.
When enabled, longer-running reverse-execution commands will replay execution history across multiple CPU cores. The speed-up achieved will depend on how far back in history the command moves; the more history executed, the greater the benefit.
Configuring Parallel Search¶
Parallel Search is disabled by default. To enable it, set the environment
When this is set, UDB will automatically enable Parallel Search and start using multiple CPU cores (up to four cores will be used for a 64-bit debugged process, or up to two cores for a 32-bit process) to execute reverse-execution commands.
If you enable Parallel Search, please mention this when submitting support requests, even if the problem does not appear related.
The maximum speed-up is determined by the number of CPU cores used. Reverse-execution speed can be increased by up to four times.
For reverse-execution commands with short runtimes (less than 2 seconds or so), Parallel Search does not provide a significant benefit and may incur a small slowdown in some cases, though this should be minimal.
If you experience any significant slowdowns when debugging with Parallel Search enabled, please report the issue to firstname.lastname@example.org so that your use case can be optimized.
During reverse-execution commands with Parallel Search enabled, UDB will start additional processes to replay execution history, with runtime behaviour similar to a parallel build.
The memory and CPU use of the debugging session will therefore be higher than normal. As with a parallel build, the additional activity may impact other processes (and users) on the machine.
Parallel Search is enabled only if all these conditions are met:
UNDO_parallel_search=trueappears in the environment.
The host has at least two available CPU cores.
The host has memory overcommit enabled, that is,
0. (This is the default behaviour on most Linux distributions.)