The current version is exhibiting worse routing performance compared to the baseline established in v1.9.

Specifically, on the benchmark design Issue508-DAC2020_bm01.dsn, the router fails to converge as quickly as the previous version during the initial passes.

Target Metric

• Goal: 5 unrouted items (not nets) after the first 5 passes.
• Current Behavior: 74 of unrouted items after 5 passes.

Reproduction / Benchmark Command
Run the router in CLI mode using the following command to reproduce the issue. Note that this forces single-threaded execution and disables auxiliary modules to isolate the core routing logic.

-de .\tests\Issue508-DAC2020_bm01.dsn -do .\tests\Issue508-DAC2020_bm01.ses --router.optimizer.enabled=false --gui.enabled=false --api_server.enabled=false --router.job_timeout="00:00:30" --router.max_passes=5 --router.max_threads=1 -ll debug

Implementation & Investigation Guidelines

• Logging: Add detailed debug logging to PerformanceProfiler (using job.logDebug() or FRLogger.debug()) to analyze the bottleneck.
• Constraints:
• Focus strictly on single-threaded performance (--router.max_threads=1) for now.
• Do not run full unit test suites until the specific benchmark passes.
• Ignore .rules files; rely on input DSN (-de) and output SES (-do).
• Ensure any logic changes remain thread-safe, even though we are debugging in single-threaded mode.

Potential Root Cause: Stopping Conditions
The heuristics for the "Stopping Conditions" appear suboptimal in the current snapshot. We likely need a better method for deciding when to:

1. Halt attempts.
2. Restore older board states.
3. Continue to the next pass.

Task Checklist

• Instrument PerformanceProfiler with debug logs to capture state after the first 5 passes.
• Analyze the "Stopping Conditions" logic and identify where it diverges from the optimal path.
• Refactor heuristics to prioritize minimizing unrouted items early.
• Verify fix against Issue508-DAC2020_bm01.dsn using the CLI command above.