Find the cost, then remove it.
A plugin that uses four percent of a core is a plugin people put on every track. One that uses fifteen gets used once per session, and then gets replaced.
We profile on the hardware your customers actually run, find where the time goes, and remove it. Every change is measured on both sides, so the improvement is a number rather than an impression.
Real sessions on real machines, Apple silicon and x86. Instruments, perf, and the plugin host's own load figures, taken at the buffer sizes your users work at.
Denormals, cache misses, work done per sample that belongs per block, allocation on the audio thread, and locks in places nobody meant to put one. These account for most of what we find.
SIMD across NEON and AVX, and parallelism where the algorithm genuinely allows it. Both are applied after the structural work, since they multiply whatever is already there.
A benchmark in your CI so a regression shows up as a failed build rather than as a customer report six months later.
It depends entirely on the starting point. Codebases that have never been profiled often have a two to five times gain sitting in one or two functions. Tuned code is a harder and more incremental job.
Only if you agree to it. We aim for bit-exact output, and where a change alters it we say so and quantify it.
Yes, including NEON paths and the memory behaviour that differs from x86.