[Tracking] Performance & Architectural Optimizations (community feedback)

[majockbim]

Background

After posting on r/cpp, the community provided detailed profiling insights
and architectural feedback. This issue tracks the actionable improvements
identified.

Special thanks to u/juanfnavarror, u/SkoomaDentist, u/ack_error,
u/lonkamikaze, u/unicodemonkey, and u/BusEquivalent9605.

Key Findings

The real bottleneck is not the FFT, it's console output.
u/ack_error profiled the process directly:

• FFT accounts for < 10% of CPU time
• ~40% of CPU is spent in kernel (console writes + Sleep() calls)
• Windows Terminal itself uses 4x the CPU of spectrum.exe

log10() calls are more expensive than the FFT itself.
Currently all 1201 FFT bins go through dB conversion even though most
don't map to UI bars. This is unnecessary compute.

Hop size is mismatched to render rate.
A 2.5ms hop (120 samples) produces ~6 FFTs per frame at 60Hz - 5 of
which are discarded before the UI reads them.

Milestones

• Profile with a proper profiler to confirm findings before touching anything
• Shift dB conversion (log10) out of FFT loop - only convert bins that map to UI bars
• Increase HOP_SIZE to match render rate (~800 samples at 48kHz/60fps)
• Investigate console write optimization (batch writes, reduce syscall frequency)
• Research Multi-Resolution Analysis (MRA) - short FFT for highs, long for lows
• Research downsampling for low-frequency path (suggested by u/SkoomaDentist)
• Evaluate lock-free ring buffer (suggested by u/BusEquivalent9605 - JACK's jack_ringbuffer)

Notes

Per u/juanfnavarror: mutex contention is likely near zero given the rate
disparity between audio capture (48kHz) and render (60Hz). Lock-free
optimization is low priority until profiling proves otherwise.

Per u/lonkamikaze: the profiler doesn't always surface the highest-impact
changes. Clean code paths matter too.

Full thread: r/cpp post

the C++ community is so cool :D