Recording costs almost nothing.

• 277 ms to the window's first frame, the pond's garden built before it, over its 58.7 ms budget
• 1.55% of one core for the whole of Manfred while it records your microphone, over its 0.5% budget
• 0.12% of one core for the loudness meter and the peaks, over its 0.1% budget
• 400 ms to export a one-hour recording as WAV

Starting, recording, listening

Each number has a release budget, set as the number measured on the day its row was added plus 5%, and checked by Manfred's speed script before every release. A number over its budget is reported here, against the old budget, and never written over; Manfred marks those rows as over.

• 0.84 ms manfred --version, start to exit process start to exit, median of 20, at a load of 27.3 (0.83 ms on 2026-10-18)
• 1.18 ms manfred list --json, 50 recordings 50 one-minute recordings, median of 10, at a load of 27.3 (2.21 ms on 2026-10-18)
• 277 ms The window's first frame the gui --shot wall time at 1280x800, minus the readback and PNG a window doesn't do, median of 3, at a load of 27.3. In the median run: 62 ms building the app with its device lists; then, in parallel, the GPU device (51 ms) and the renderer (126 ms, 61 ms of it decoding the plates and 11 ms building the pipelines), which the first frame waits 115 ms for; then 35 ms for the frame and its render. The rest is the process start Over its 58.7 ms budget. This row now times a different window: the 55.9 ms of 2026-10-18 was the old egui window, and since 1.2.0 the window is the pond, which builds its garden before the first frame. The pond window measured 105 ms in a 2026-10-18 rerun; no run splits the step from 105 to 277 ms.
• 266 ms First audio in the file from record start to the first audio bytes in the .manf file, fake mic, median of 10, at a load of 26.0: the writer's 250 ms flush plus one 5 ms tick (264 ms on 2026-10-18)
• 1.27 % The writer, recording the writer threads, 48 kHz mono, meters and peaks on, noise gate on, at a load of 26.0; nearly all of it the manfred-writer thread (1.02%), with manf-writer at 0.25% Over its 0.37% budget (0.35% on 2026-10-18). The writer carries more work since: lossless compression of the sound, the pond's per-channel envelope and pitch, and since 1.2.0 the noise gate. A 2026-10-18 rerun that already had the first two measured 1.07%; no run separates the three. The writer rows with live transcription on the CPU (1.09%) and the GPU (0.98%) and with the 1080p30 camera (0.91%) are over their budgets too.
• 0.12 % The meters and peaks, recording the loudness meter and the waveform peaks the writer runs, measured alone, at a load of 26.9 Over its 0.1% budget (0.1% on 2026-10-18). That budget is 0.1% plus 5% rounded back to 0.1%, so any rise reads as over. Measured at a load of 26.9 and not re-run.
• 1.55 % The whole process, recording 48 kHz mono, no transcription, no camera, at a load of 26.0 Over its 0.5% budget (0.48% on 2026-10-18): the process rows follow the writer rows.
• 2.1 % Live transcription on the GPU, whole process Whisper on Vulkan included, 60 s of speech, median of 3, at a load of 16.9; each 20-second window heard in 0.22 to 0.29 s (2.07% on 2026-10-18)
• 16.7 % Live transcription on the CPU, whole process Whisper included, 60 s of speech, at a load of 26.9; Whisper's processes take 15.5% of it, and each 20-second window took 0.88 to 1.12 s to hear Over its 14.1% budget (13.4% on 2026-10-18, each window heard in 0.7 s). A 2026-10-18 rerun at a load of 16 to 46 measured 19.2%, which points at contention on a busy machine, but it is not proven, and the run was not repeated.
• 22.0 % The whole process with a 1080p30 camera a synthetic 1080p30 camera through the GPU encoder, median of 3, at a load of 10.0: the only real cost while recording, mostly the camera thread turning frames into I420 (15%) and the encoder thread feeding VA-API (5.7%) (24.4% on 2026-10-18)
• 0.67 ms The window's frame at 1600x1000, median the pond window while recording, demo data, offscreen, 600 frames, median of 3 runs, at a load of 17.8: 0.99 ms at the 99th percentile and 1.2 ms for the worst frame, inside the 8.3 ms a 120 fps frame allows
• 1.19 ms The window's frame at 2560x1440, median the same 600 frames at 2560x1440, median of 3 runs, at a load of 18.6: 1.5 ms at the 99th percentile and 1.64 ms for the worst frame
• 0.16 ms The terminal's frame, median the Record screen at 120x34 while recording, 600 frames, at a load of 17.8: 0.3 ms for the worst frame; the Open screen 0.16 ms (worst 1.23 ms) and the Export screen 0.12 ms (worst 0.33 ms)

Exports

Measured in the same run with the speed script's own steps, three runs each, median kept, at a load of about 18; the two WAV rows and the Free version's export are release budgets, and each held. The turned camera comes from Manfred's bake bench.

• 400 ms Audio, WAV a 1-hour recording, 48 kHz mono F32, no noise gate, 691 MB out, synced, bit-identical, median of 3, at a load of 18.6 (542 ms on 2026-10-18)
• 938 ms Audio, WAV, a gated take the same hour recorded with the noise gate (3 s open, 1 s shut), the gated sound rebuilt from the raw microphone and the gate's marks, 691 MB out, median of 3, at a load of 18.6: about 0.5 s more an hour than a plain take, because each sample passes through the gate's gain again
• 44.6 ms Video, MP4 stream copy 10 minutes of the camera test card at 1080p30 H.265 copied, no sound, 7.5 MB: 268 ms an hour (325 ms on 2026-10-18); a real webcam at full quality writes more video bytes than the test card, and 1080p30 H.265 at 12 Mbit/s with its sound is about 5.5 GB an hour by Manfred's format bench
• 181 ms Audio and video, MP4 the same 10 minutes plus 48 kHz mono AAC-LC at 192 kb/s encoded on all 32 threads, 22 MB: 1.09 s an hour (1.98 s on 2026-10-18)
• 7.67 ms Subtitles, SRT a 1-hour transcript, 815 segments read from the .manf and cut into 1,365 cues (16.6 ms on 2026-10-18)
• 4.2–7.2 s A turned or mirrored camera, 60 s at 1080p the turn baked into the pixels and encoded again in H.265 on the GPU (VA-API), 250 to 430 fps, a 60 s take of the camera test card at 30 fps with the GPU shared with other jobs, by Manfred's bake bench; the same take with no turn is a stream copy in 0.01 s
• 14.6 s Free version, audio and video, 5 minutes manfred export --both on a Free install: decoded, re-encoded on the GPU with the mark, then joined with the AAC sound, median of 3, at a load of 18.0; 21 times real time (15.0 s on 2026-10-18)

Storage

Measured by Manfred's format bench, not a release budget.

• 217 MB An hour of speech on disk 48 kHz 24-bit mono compressed losslessly as it records: 41.9% of 518 MB raw (flac -5 on the same file: 41.2%), the writer thread at 0.12% of one core; 600 s of public-domain NASA speech pushed as the recorder pushes it, by Manfred's format bench, 2026-10-18. A take with the noise gate stores only the untouched microphone and a few bytes a second of the gate's decisions, so it is the same size

What a take can lose

The most a take can lose. These are not measured: they follow from how the writer flushes and syncs a take, and hold while the disk keeps up. The writer can queue tens of seconds of media for a disk that falls behind, and a crash or a power cut loses whatever is still queued.

• 0 ms Stopping a take Stop writes the index and the trailer and syncs, so the whole take is on disk
• ≈250 ms Manfred killed mid-take a killed process keeps everything up to the recorder's last flush; the recorder checks every 5 ms tick and flushes once 250 ms have passed, so the most it loses is 250 ms plus up to a tick and the loop's time, as the 266 ms to the first audio in the file shows
• ≈500 ms The power cut mid-take the writer syncs to the disk whenever 500 ms have passed with anything unsynced, so a power cut keeps everything up to the last sync, at most about 500 ms back

Recording under stress

Measured 2026-10-20 on commit bb58edd, a release build from after v1.1.0-alpha.7 and before the noise gate: 60-second takes of a public-domain voice recording and a synthetic 1280x720, 30 fps webcam encoded to H.265 on the GPU, the window on a headless compositor at 2560x1440 and 240 Hz, at a load average of 10 to 22. Test-build hooks froze the window's thread or slowed every disk sync; they were a patch applied for the proof and are not in the product. Expected counts are the stop time times 48 kHz and times 30 fps. Manfred 1.2.0 keeps every one of these buffer sizes, and its writer also carries the noise gate's marks, a few writes a second; the stress run itself has not been repeated on 1.2.0.

• 0 dropped The window's thread frozen 500 ms, six times in 60 s 2,919,360 of 2,919,424 samples, 0 dropped (the 64 short are the last 10 ms block at the stop), and 1,825 of 1,825 frames; the window shows six 504 to 505 ms frames, the stalls themselves
• 0 dropped Every disk sync slowed by 0.4 s no sound dropped, and 1,824 of 1,824 frames captured; the window's p99 frame 8.65 ms, with pfx sharing the card
• 0 dropped Every disk sync slowed by 20 s no sound dropped, and 1,824 of 1,824 frames captured, the window running throughout: 20 s waits in the writer's queue and 5 s more in the microphone's ring
• 18.2 s dropped Every disk sync slowed by 40 s, past the buffers 874,080 samples of sound and 447 frames dropped, every one counted; the take was still saved, with no failure, the dropped sound is silence in its place so the picture stays in sync, and the window said what was lost: “18210 ms were lost and are silence. 447 video frames were dropped.” The window ran at 239 fps throughout, p99 8.87 ms with pfx at 26% of the card

Starting, recording, listening and the exports, the turned camera aside, were measured 2026-10-21 by Manfred's own speed script on the product code of v1.2.0 (tag v1.2.0, 9e86f1d), built from a commit whose crates, sources, Cargo.toml and Cargo.lock are byte for byte the tag's, as a release build (LTO, stripped), on an AMD Ryzen 9 9950X (32 threads) and an AMD Radeon RX 9060 XT (VA-API) under Arch Linux. Other agents' builds and pfx renders shared the machine and the card throughout: the load average went from 26.3 to 17.9 during the run, and each row of the first table, the two WAV exports and the Free version gives the 1-minute load when its step started, and the MP4 and SRT exports ran at about 18. CPU is percent of one core. Linux only: Windows and macOS have no numbers here.

A raw WAV export gives back the recorded bytes exactly.