Begin with a reproducible symptom
Describe the slow case using an input file, model revision and exact runtime configuration. Keep the application’s total elapsed time before collecting a detailed profile. A profiler is most useful when it explains a known symptom; otherwise a long list of operations encourages tuning whichever line looks largest. Include a successful comparison case if one exists, but avoid changing input size and runtime settings at once. The aim is to isolate a difference that can be examined.
Use the trace at its proper scale
ONNX Runtime can emit a JSON performance trace containing operator timing and threading information. That supplies a view inside model execution, rather than a replacement for the application clock. Look for repeated work, expensive operations and gaps that deserve investigation. Record the provider configuration with the trace. A high host CPU reading does not by itself establish unsupported accelerator operations, since capture, preprocessing and output handling may also need the processor. Confirm execution details before naming the cause.
Turn observations into a small experiment
Choose one proposed explanation and a change that could disprove it. For example, hold the model fixed while removing display work, or hold application inputs fixed while comparing runtime settings. Keep the expected effect written down before the rerun. This prevents a faster result from being retroactively explained by any difference in the setup. If the profile does not cover a suspected stage, add an application timestamp at that boundary rather than asking the runtime trace to explain invisible work.
Return to the user-visible task
After a promising change, repeat the unprofiled workload and inspect output correctness. Detailed instrumentation can affect the workload it observes, and a shorter operator duration may have little effect on total response time. Keep both kinds of evidence with the change record. The decision to retain a setting should rest on the application requirement it improves, its maintenance cost and the behaviour it preserves. A trace is an investigative tool, not a performance score for the board.
Sources & publication notes
Retrospective period: September 2025. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.