Composer Reference Guide R2-2026-2.6.9642.28010

Performance report

Composer can dump a comprehensive performance report — a plain-text snapshot of the host, the project, and the runtime metrics accumulated since the project started — that's the right artefact to attach to a performance ticket or to compare two systems against each other.

How to generate one

  • Composer Desktop — Analysis → Performance Report menu.
  • HTTP API — GET /api/reports/getperformancereport returns the report inline as text/html and (as a side-effect) writes the same report to disk. See HTTP API → reports for the endpoint reference. This is the way to fetch a report from a headless Runtime host or from automation.

Either path generates the report synchronously — typically under a second on a healthy host.

Where it's stored on disk

Every generated report is also written to disk so support tickets can attach it without copy-pasting from a window:

  • Location: <application-root>/Reports/ — i.e. next to the Composer executable.
    • Installed Desktop: C:\Program Files\RealSprint AB\Vindral Composer\Reports\
    • Headless Runtime: the runtime's install/working directory, under Reports/.
  • Filename pattern: PerformanceReport_<YYYYMMDD>_<HHmmss>_<fff>_<pid>.txt — date, time, milliseconds, process id. Multiple reports from the same session don't collide.
  • Retention: Composer never prunes the folder; old reports accumulate until you remove them.

What the report contains

The report is a single plain-text file with section headers (Section name: / --------); easy to grep or paste into a ticket. Sections, in order:

  • Application info — application name, release line, version, alias name, license type, license company, license key, host name.
  • Project info — project file path, project key, session up-time, frames processed since start, congestive frame count, frame rate, preferred sync source, preview renderer name, live-preview-active flag.
  • System info — Windows vs. Linux, OS version, CPU model, full OsInfo and ComputerInfo dictionaries (Windows), GPU name, full CudaGpu device dictionary (clocks, memory, SM count, ECC state, driver version, …).
  • Settings snapshot — at minimum LockGPUClocks. Other tuning-relevant settings can be inspected via the settings.xml reference.
  • Capture devices — Decklink devices and channels currently mounted, plus the active sync source.
  • Performance — time-to-first-frame; CPU usage; current and 10-minute average / min / max RAM; processing time over the last 10 000 frames (ms and as a percentage of frame budget); GPU power %, utilization %, temperature, power-management state, power state (0–8), encoder utilization %, decoder utilization %, PCIe link width, GPU memory total / used / free.
  • Audio settings & performance — number of audio channels, parallel audio processing on/off, summed and wall-clock input audio render times, audio-capable input count, virtual-audio-strip render time, VU-meter state.
  • Project lifetime statistics — warmup state, total samples, lifetime mean / std-dev / min / max with timestamps, max +/- jitter with timestamps, frame-budget headroom (avg and worst-case), and budget-exceeded frame count and percentage.
  • Scenes — per-scene average processing time, scene count, sum.
  • Inputs — per-input average processing time, ordered slowest first.
  • Sum processing time by type — totals grouped by component class with instance counts.
  • Detailed performance metrics — Top 10 worst spikes (by lifetime max), Top 10 highest averages (10k-frame window), Top 10 highest jitter, plus per-component tables for Scenes, Inputs, Operators, and Targets with Avg50, Avg10k, lifetime mean / std-dev / min / max, +/- jitter, and budget-exceeded counts.
  • Assets — found / not-found media files, found / not-found referenced directories, found / not-found script files (main script + recursively imported .js modules).

What to look for

  • CPU temperature ≥ 83 °C — the host is throttling; cooling is undersized.
  • GPU PCIe link width below x16 — a slot is electrically narrow or a riser cable is bad; the GPU isn't getting the bandwidth it could.
  • GPU power state varying under sustained load — clock locking isn't in effect; the GPU is dropping back to idle clocks between frames.
  • One component dominating processing time — usually a tell that a single operator or encoder is over-budget; consider replacing it with a cheaper alternative or moving its work to NVENC / NVDEC.
  • Assets-not-found list non-empty — a media file or LUT moved on disk; the project will run with that asset blank or black until you fix the path.

Sharing with support

Run the report, then attach the resulting PerformanceReport_*.txt from the Reports/ folder to your support ticket alongside a Logs/ snapshot from the same period — see Log files for the log layout. For headless runtime hosts, fetch via GET /api/reports/getperformancereport and pipe the response straight to a file.