Hotspot: Linux perf CPU profiling

Hotspot displays Linux perf CPU profiles. Use it to investigate native C/C++ work in Reckfell 1.0.0; a CPU profile is not a GPU frame capture or a complete managed C# call tree.

Prepare a reproducible target

You need Linux, a working perf installation, Hotspot, a reproducible project action and the exact executable with matching debug symbols. Keep the binary, libraries and source from the recording. Rebuilding afterward can make addresses refer to different code.

For a representative measurement, preserve the optimization and renderer settings you intend to investigate. A dev_build=yes build can execute extra development checks and use different optimization. debug_symbols=yes enables native symbol information; it does not itself select production-equivalent performance. See the native profiling workflow and source build instructions. Separate symbols, if enabled, must remain available alongside the matching artifacts.

Choose the game process for runtime work or the editor for editor work. Project Manager can launch another process. Check executable path and arguments instead of selecting the highest PID. --path identifies the directory containing project.reckfell; add --editor only when measuring the editor. Do not use --quit for a steady workload: it exits after the first main-loop iteration.

Record and open a profile

Replace the /absolute paths below. The output path is deliberately separate from the project. This starts the game, not the editor:

perf record -o /absolute/capture/perf.data --call-graph dwarf -- /absolute/Source/bin/reckfell.linuxbsd.editor.x86_64 --path /absolute/project
hotspot /absolute/capture/perf.data

The binary name is an example for the selected editor build; use the actual build output. Create the output directory first. Perform the action, close the game normally, then run the second command. Expected result: a nonempty perf.data and samples from the intended process. For other recording options, use the documentation matching your installed perf.

Hotspot can also launch or attach through Record Data. Launch includes startup; attach or filter the recorded time interval when startup is outside the question. Recording permissions depend on the Linux host; diagnose the actual perf error instead of routinely launching the entire IDE/profiler as root. See the Hotspot recording and troubleshooting reference.

Read the result

Filter to the relevant process, thread and time interval before interpreting a flame graph. With ordinary on-CPU sampling, a wider stack represents more sampled CPU cost for the selected event, not a measured duration of one call. Inclusive cost includes callees; self/exclusive cost excludes them. Check callers before changing a shared utility: many cheap calls and a few expensive calls require different fixes.

CPU sampling alone does not explain time spent sleeping, waiting for GPU completion or blocked on I/O. Correlate it with frame measurements and, when needed, an appropriate wait/trace capture. Do not infer a GPU bottleneck solely from a low CPU sample count. Keep the same action, build, quality settings and recording options when comparing before/after; report frame-time changes separately from sample percentages.

Diagnose incomplete data

Verification limits

Engine options and process selection were checked against current source and retained Windows CLI evidence. Hotspot/perf procedure was reviewed against primary documentation. No Linux capture, symbol resolution, profiler GUI, managed stack, GPU timing or speedup was verified here. Source, Runtime and SDK unchanged.