Add --duration flag to perf for time-budgeted benchmarking

[xieofxie]

Summary

Adds a --duration <seconds> flag to winml perf. When set, the benchmark runs for a wall-clock time budget instead of a fixed --iterations count. After warmup, inference loops until the duration elapses (always running at least one benchmark iteration so stats are never empty).

This is ideal with --monitor, whose PDH hardware counters need time to emit real utilization data — a small fixed iteration count often finishes before the counters produce meaningful samples.

winml perf -m model.onnx --device npu --monitor --duration 15

Details

• New --duration FLOAT option (must be > 0), plumbed through BenchmarkConfig.duration.
• _benchmark_indices() helper centralizes the loop: warmup first, then either a fixed iteration count (default) or a timed loop. Used by the single-model, monitored, and per-module paths.
• Mutually exclusive with --op-tracing (op-tracing runs its own fixed, small iteration count) — rejected with a clear UsageError.
• Live --monitor chart shows elapsed/total time progress (Time: 12.3/30s) in duration mode instead of an iteration counter.
• Accurate iteration reporting: in duration mode the reported iteration count reflects the actual number of timed samples rather than the unused --iterations default. For per-module runs (where each module runs a different count under a shared budget), the count is recorded per instance and the top-level value is null; both single-model and module reports also record duration_sec.
• --duration is added to the genai "ignored flags" warning (genai benchmarks by token generation).

Tests

• --duration help/forwarding/default, --op-tracing conflict, non-positive rejection.
• _benchmark_indices iteration mode, timed budget, and at-least-one-iteration guarantee (deterministic via a faked clock).
• LiveMonitorDisplay time-based vs iteration-based progress.
• benchmark_info.iterations reports configured count without duration and actual sample count with duration.

All perf suites pass (test_perf_cli, test_perf_module, test_perf_composite, test_ep_monitor): 200 passed, 2 NPU-only skips; ruff clean.

[xieofxie]

Needed for #1149

[DingmaomaoBJTU]

Took a pass through this — the overall approach looks good. The warmup→timed-loop split, the at-least-one-iteration guarantee, the --op-tracing conflict, and the genai ignored-flag warning are all correct, and the tests cover the important paths.

A few minor nits (none blocking):

perf.py L732-734 — logger.info("Running benchmark: %d iterations + %d warmup", ...) still logs the fixed iterations count in --duration mode, so it reads e.g. "Running benchmark: 100 iterations + 10 warmup" for a run that's actually time-bounded. Might be worth branching to log the time budget there.

Two more inline below.

[DingmaomaoBJTU]

In --duration mode i keeps counting past total_iterations (the loop is time-bounded, not count-bounded), so this progress log can read e.g. Progress: 350/110. The total_iterations denominator here — and on the logger.debug line just below — is meaningless once the run is timed. Minor since it's debug-only, but might be worth switching to an elapsed/duration readout in duration mode.

[DingmaomaoBJTU]

This stamps _bench_start on the first post-warmup update(), which runs after that iteration's session.run(). But _benchmark_indices starts its own budget clock before that run (perf.py L1771) and the loop terminates on the generator's clock. Net effect: this display clock lags by ~one inference, so Time: x/Ns tends to finish a bit under 100%. Purely cosmetic — if you want the bar to land on 100%, share the generator's start timestamp with the display instead of re-stamping here.