Composer Reference Guide R3-2026-2.7.9774.35170-prerelease

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 → Create performance report…, or the Create Performance Report button in the CPU and GPU performance section of the Performance tab. The project must be saved first; an unsaved project gets a prompt to save and no report. When the report is ready it is copied to the clipboard, and a dialog shows where the file was written.
  • HTTP API — GET /api/reports/getperformancereport returns the report as a simple HTML page (the same text, one line per row) and writes the same report to disk. It needs the read role when API keys are in use. See Statistics & monitoring 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. It opens with the date and time it was created. 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, Render Tuning state (Active / Not active) and — when active — how many inputs it is currently not rendering and how many are set to manual control.
  • System info — Windows vs. Linux, OS version and CPU model. On Windows it also lists the operating-system and computer details, the GPU name and the GPU's device details (clocks, memory, SM count, ECC state, driver version, …); on Linux the section stops after the CPU model.
  • Settings — Lock GPU clocks. 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. Only present when the host has DeckLink capture hardware.
  • 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 (P0 is full performance; higher numbers are lower-power states), 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 — warmup status; a summary per category (scenes, inputs, operators, targets) with total 10k-frame average, total lifetime mean, worst lifetime max and best lifetime min; Top 10 worst spikes (by lifetime max, with when it happened), Top 10 highest averages (10k-frame window), Top 10 highest jitter; then per-component tables for Scenes, Inputs, Operators, and Targets with Avg50, Avg10k, lifetime mean / std-dev / min / max, +/- jitter and budget-exceeded counts, each followed by that category's worst spike and worst jitter with timestamps.
  • Assets — found / not-found files: media used by video, audio, still-image and CAV inputs, the project script, and files used by operators (keyer garbage mattes and clean plates, LUTs, object-detection and speech-to-text models, wheel-tracker texture atlases, difference-matte clean plates). Then found / not-found referenced directories, and found / not-found script files (main script + recursively imported .js modules).

What to look for

  • Budget Exceeded Frames above 0 %, or a negative Worst-case Headroom — some frames took longer than the frame budget, which is where dropped or repeated frames come from. Compare with Number of congestive frames since start and the Top 10 worst spikes to see when it happened and which component caused it.
  • High GPU temperature — NVIDIA GPUs start lowering their clocks in the low-to-mid 80s °C, so a GPU running that hot is probably throttling; check the host's cooling and airflow. (The report does not include CPU temperature.)
  • 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.
  • Render Tuning active with an unexpectedly high not-rendered count — an input that looks frozen is most likely paused because no rendered scene uses it; check the layer's visibility, opacity, and audible state, or set that input to manual control.

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, call GET /api/reports/getperformancereport: the response is the report as HTML, and the same call writes the plain-text PerformanceReport_*.txt to the host's Reports/ folder, which is the file to attach.