0

I'm currently developing an audio application and the performance is one of my main concerns.

There are really good articles like Four common mistakes in audio development or Real-time audio programming 101: time waits for nothing.

I understood that the c++ is the way to go for audio processing but I still have a question: Does Objective-C++ slow down the performance?

For example with a code like this

@implementation MyObjectiveC++Class

- (float*) objCMethodWithOnlyC++:(float*) input {
    // Process in full c++ code here
}

@end

Will this code be less efficient than the same one in a cpp file?

Bonus question: What will happen if I use GrandCentralDispatch inside this method in order to to parallelize the process?

DEADBEEF
  • 1,930
  • 2
  • 17
  • 32

2 Answers2

1

Calling an obj C method is slower than calling a pure c or c++ method as the obj C runtime is invoked at every call. If it matters in your case dependent on the number of samples processed in each call. If you are only processing one sample at a time, then this might be a problem. If you process a large buffer then I wouldn't worry too much.

The best thing to do is to profile it and then evaluate the results against your requirements for performance.

And for your bonus question the answer is somewhat the same. GCD comes at a cost, and if that cost is larger than what you gain by parallelising it, then it is not worth. so again it depends on the amount of work you plan to do per call.

Regards Klaus

KlausCPH
  • 1,816
  • 11
  • 14
1

To simplify, in the end ObjC and C++ code goes through the same compile and optimize chain as C. So the performance characteristics of identical code inside an ObjC or C++ method are identical.

That said, calling ObjC or C++ methods has different performance characteristics. ObjC provides a dynamically modifiable, binary stable ABI with its methods. These additional guarantees (which are great if you are exposing methods via public API from e.g. a framework) come at a slight performance cost.

If you are doing lots of calls to the same method (e.g. per sample or per pixel), that tiny performance penalty may add up. The same applies to ivar access, which carries another load on top of how ivar access would be in C++ (on the modern runtime) to guarantee binary stability.

Similar considerations apply to GCD. GCD parallelizes operations, so you pay a penalty for thread switches (like with regular threads) and for each new block you dispatch. But the actual code in them runs at just the same speed as it would anywhere else. Also, different from starting your own threads, GCD will re-use threads from a pool, so you don't pay the overhead for creating new threads repeatedly.

It's a trade-off. Depending on what your code does and how it does it and how long individual operations take, either approach may be faster. You'll just have to profile and see.

The worst thing you can probably do is do things that don't need to be real-time (like updating your volume meter) in one of the real-time CoreAudio threads, or make calls that block.

PS - In most cases, performance differences will be negligible. So another aspect to focus on would be readability and easy maintenance of your code. E.g. using blocks can make code that has lots of asynchronicity easier to read because you can set up the blocks in the correct order in one method of your source file, making the flow clearer than if you split them across several methods that all just do a tiny thing and then start an asynchronous process.

uliwitness
  • 8,532
  • 36
  • 58