A proper way to profile the performance

[ChunMinChang]

When the C/C++ backend is rewritten in Rust, it needs to make sure the performance is not dropped (Rust version might not outperform the C backend at first when it's directly translated). When we do some refactoring, we also need to check the performance becomes better. I believe it's better to define the benchmarks. It would be an important checkpoint to know the changes we made are right.

However, I don't have clearer ideas about the definitions of the benchmarks. Maybe it's better to simulate the behaviors of how the cubeb streams work in Firefox.

[padenot]

In general, cubeb should not be appearing anywhere in profiles.

Startup time for a stream really is dependent on the device, and the code is mostly doing system calls anyways, so I don't think we'll see any difference.

The only bit that can appear is resampling or the other light DSP we do (up/down mix, etc.), but that's not been rewritten.

[ChunMinChang]

The cubeb does more things than just system calls. How we create the critical section will impact the performances as well. The performance test will assist us in evaluating the approaches we take, such as

• mutex v.s. lock-free method
• creating an aggregate device for AudioUnit v.s. using VoiceProcessingIO AudioUnit

Now we reply on experience or instinct to improve the code. However, I'd like to see something that can confirm the changes are right. I know sometimes it's nice to have some refactoring that makes the code more manageable with a little performance drop. Or sometimes we must fix the problems as soon as possible without worrying too much performance. But it's good to check the performance periodically to make sure the cubeb is fast enough.