Web UI

Workflow tab

The end-to-end pipeline in four numbered steps, driving exactly the same code as the CLI.

Project and configOpening a project reports its source count, build system and instrumented binaries; the preview shows what the current config selects.

1. Project — browse the filesystem (directories badged make/cmake) and open one. You get the source count, the detected build system, and any instrumented binaries already present.
2. trace.config — an editor with save, a selection preview (N sources: X instrumented, Y excluded), and a call-subtree helper: type a function name and optional depth to resolve its subtree through the static call graph and append the matching include-func line.
3. Build & run — one-click instrumented build (make instrument or the CMake flow) with the full log captured, then run the binary with TRACE_ENABLE=1, a TRACE_MAX cap and a timeout.
4. Report — the analyzer result as a sortable table: calls, inclusive and self time, plus the per-call p50, p99 and max, with the summary line turning green on unmatched_exits=0. Anything that cut the capture short is called out above the table.
5. Flame graph — the same collapsed stacks the CLI exports, rendered in the browser. Each frame is as wide as the time spent inside it; click one to zoom into that subtree and click it again to zoom back out.

The reportClick any column header to re-sort. Rows arrive ordered by self time, so the hot leaves are on top.

Config Builder tab

A visual editor for trace.config — no pattern syntax to memorize.

Files on the left, functions on the rightBoth panes filter live; the symbols: badge names the backend that produced the scan.

1. Pick a folder and scan. The builder enumerates every source file and the functions defined in them. It uses ctags when available — a symbols: badge next to the Scan button tells you which backend served the scan: system ctags, the bundled static copy (auto-downloaded on first scan), or the built-in regex fallback.
2. Searchable checkbox panes — one for files, one for functions. Filter either list and tick what you care about.
3. Per-function actions — for each selected function choose include-subtree (expands through the static call graph, like include-func), exclude, or count.
4. Preview — writes the generated config, then dry-runs the selection against it: how many sources would be instrumented versus excluded with your current choices. (The write is required — the dry run reads the saved file.)
5. Apply — writes trace.config into the project, ready for the next instrumented build.

Both buttons ask before overwriting an existing config whose content differs.

Choosing what to count

The Count action selects functions for hardware counters. Because a counter read is not free — and on arm64 it is a syscall of microseconds — the panel below the panes exists to stop you pointing them somewhere useless:

• A capability banner from the actual machine. The server opens a real counter and runs a known loop before the panel offers anything. Where the PMU is not exposed — most containers — Count is disabled and says why, rather than letting you configure a run that would report zeros.
• Event checkboxes, capped at three. A fourth is refused: past the PMU's registers the kernel time-slices the events and scales the counts, which turns exact numbers into estimates.
• Each function's median duration from the last analyzed run, shown on its row. Anything below the floor is dimmed and badged too short.
• Check selection resolves the names against the built binary and projects the cost: two reads per counted call, so the previous run's call counts give a real number — “+4.2 ms on a run that took 8000 ms” — before you run rather than after. It also names anything that did not resolve, or that carries no instrumentation hooks and therefore can never be counted.

Live tab

A report that fills in while the program is still running, instead of after it exits.

• Run & watch launches the binary from the UI and reads its trace as it grows.
• Watch a directory follows one that something else is filling — a callsight serve receiving from a remote device, which is where this earns its keep: a 32-bit or big-endian board streaming in, symbolized and counted on arrival.

The header shows elapsed time, thread and function counts and an events-per-second sparkline; the table is the current top functions by self time, with counter columns alongside when the capture has them. Stop sends SIGTERM first, so a clean exit still flushes each thread's buffered tail.

Each refresh reads only the bytes the trace files have gained since the last one — a partial final record is resumed rather than dropped — so the cost is proportional to new events, not to the size of the trace. A capture heading for millions of events refreshes just as cheaply at the end as at the start.

Symbol enumeration

The builder needs to know what functions a project defines. In order of preference:

• Universal Ctags on PATH — accurate parsing, with static detection.
• The bundled static ctags — downloaded on first scan into ~/.callsight/bin and checksum-verified. Run it ahead of time with callsight provision, or inspect what would be used with the same command.
• The regex fallback — the same heuristic parser that backs include-func. Always available, no dependency.

Notes

• Everything the UI does goes through the same functions as the CLI. There are no behavior differences between driving it from the browser and from a shell.
• CMake is fetched ephemerally through uvx when the host has none, so a CMake project works without installing CMake system-wide.
• The UI's dependencies (FastAPI, uvicorn) live in the ui extra; the core package stays stdlib-only.