Timing-aware logic rewriting in synthesis is expensive because evaluating whether a candidate rewrite improves timing requires full SDF-annotated simulation for every candidate before committing. The cost is not in the rewriting; it is in the candidate selection. BBYT (Batch Before You Time) changes the unit of proxy execution from per-candidate to per-decision: all candidates for a single rewrite decision compile into one scoped zero-delay proxy image, run together, and commit the winner if the proxy separates them clearly. Only when candidates are close does the full timed evaluation run. Across 12 holdout sequences, that eliminates 32% of timed evaluations and cuts total candidate-selection time 18%, with both confidence intervals above zero on a C6288 benchmark.
The mechanism is a scope change, not an approximation. The proxy is exact for the cases it handles; it just runs at the decision granularity instead of the candidate granularity. The fidelity fallback preserves correctness on close calls. This is the same architectural insight that batching applied to GPU inference: the per-item overhead was never justified when the batch boundary could absorb it.
For synthesis teams running timing-aware rewriting in continuous integration -- OpenROAD flows, commercial synthesis scripts with ABC integration, large overnight builds -- this is a workflow-free improvement. No new configuration, no changed output, 18% faster candidate selection. The longer-term implication is that the right scope for EDA proxy execution is a decision tree problem, not a per-operation one. Tools that already batch at the design level are leaving per-decision overhead on the table. Expect this pattern to propagate to formal equivalence checking and other candidate-heavy EDA operations within a release cycle.