Reduce time spent on steiner tree construction in repair_design

[povik]

Describe the bug

@LucasYuki found more than 10 % of gpl runtime on ariane133/nangate45 is in steiner tree construction within this updateParasitics call

OpenROAD/src/rsz/src/RepairDesign.cc

Line 1102 in a46bcb2

estimate_parasitics_->updateParasitics();

.

It might be possible to replace the blanket update with

estimate_parasitics_->ensureWireParasitic(drvr_pin);

to save on runtime without degradation in result.

Expected Behavior

.

Environment

.

To Reproduce

.

Relevant log output

Screenshots

No response

Additional Context

No response

[eder-matheus]

Maybe this merged PR #9547 helped with this long runtime? After this update, we should not create Steiner trees for huge clock nets before CTS, which will probably help reducing the runtime.

[povik]

Good point. I re-run nangate45/ariane133 to check and see a roughly 10 % share in parasitic estimation. It may have improved but still has a noticable share. There's a small uncertainty to my result as symbols in the flamegraph were slightly off for some reason.

[maliberty]

Who is planning to look into this?

[Divinesoumyadip]

@maliberty I’ve been analyzing the bottleneck reported by @LucasYuki in RepairDesign.cc.

The blanket updateParasitics() call at line 1102 is indeed redundant when we are performing localized transformations. I’m currently tracing the logic to ensure that moving to ensureWireParasitic(drvr_pin) maintains the required accuracy for the slack-driven sizing engine.I’ve also noticed the shared share in parasitic estimation mentioned by @povik . I'm setting up a profile on the ariane133/nangate45 design to quantify the exact runtime delta. If the results show zero degradation in timing QoR, I can submit a PR that implements this surgical update across the rsz module.

Happy to collaborate with @LucasYuki on the verification if they've already started the implementation.

[maliberty]

I'll leave it to @LucasYuki to say if he needs help or is too far along.