我在iPhone的音频编程方面取得了一些进展。现在我正在做一些性能调整，试图看看我是否可以从这台小机器中挤出更多。运行鲨鱼，我发现我的cpu功率的很大一部分（16％）被objc_msgSend吃掉了。我知道我可以通过存储指向函数（IMP）的指针而不是使用[object message]表示法调用它来加快速度。但如果我要解决所有这些问题，我想知道我是否可以更好地使用C ++。
对此有何想法？
答案 0 :(得分：13)
目标C对于DSP /音频编程来说绝对够快，因为Objective C是C的超集。您不需要（也不应该）将所有内容都变成消息。在性能至关重要的地方，使用普通的C函数调用（或使用内联汇编，如果有硬件功能可以利用这种方式）。如果性能不重要，并且您的应用程序可以从消息间接的功能中受益，请使用方括号。
例如，OS X上的Accelerate框架是一个出色的高性能Objective C库。它只使用标准的C99函数调用，你可以从Objective C代码调用它们而不需要任何包装或间接。
答案 1 :(得分：4)
Objective-C和DSP等功能的问题本身并不是速度，而是不可避免的瓶颈何时发生的不确定性。
所有语言都存在瓶颈，但在C ++等静态链接语言中，您可以更好地预测代码中的何时何地发生。在Objective-C的运行时耦合的情况下，查找适当对象所花费的时间，发送消息所花费的时间并不是必须缓慢，但它是可变且不可预测的。 Objective-C在UI，数据管理和重用方面的灵活性可以在紧急时间任务的情况下对其进行处理。
Apple API中的大多数音频处理都是用C或C ++完成的，因为需要确定执行代码所需的时间。但是，它很容易在同一个应用程序中混合使用Objective-C，C和C ++。这使您可以为即时任务选择最佳语言。
答案 2 :(得分：3)
Objective C对于DSP /音频编程来说足够快
实时渲染
绝对不是。 Objective-C运行时及其库根本不是为满足实时音频渲染的需求而设计的。事实上，几乎不可能保证使用ObjC运行时或诸如Foundation（甚至CoreFoundation）之类的库不会导致渲染器错过最后期限。
常见的情况是锁定 - 即使是简单的堆分配（malloc，new / new[]，[[NSObject alloc] init]）也可能需要锁定。
使用ObjC是利用库和运行时，它们假定锁在其执行中的任何点都是可接受的。锁可以在等待获取锁时暂停执行渲染线程（例如在渲染回调期间）。然后你可能会错过你的渲染截止日期，因为你的渲染线程被阻止，最终导致掉线/故障。
询问专业音频插件开发人员：他们会告诉您禁止在实时渲染域中进行阻止。你不能，例如运行到文件系统或创建堆分配，因为没有关于完成所需时间的实际上限。
这是一个很好的介绍：http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
离线渲染
是的，在高级消息传递的大多数情况下，它都会非常快。在较低级别，我建议不要使用ObjC，因为它会浪费 - 如果在该级别使用ObjC消息传递（与C或C ++实现相比），可能需要花费很多很多倍。
另请参阅：Will my iPhone app take a performance hit if I use Objective-C for low level code?
答案 3 :(得分：1)
objc_msgSend只是一个实用工具。 发送消息的成本不仅仅是发送消息的成本。 这是消息启动所做的一切的成本。 （就像函数调用的真实成本是包含成本，包括I / O（如果有的话）。）
您需要知道的是来自和将来的时间占优势的消息在哪里以及为什么。 Stack samples将告诉您经常调用哪些例程/方法，以便您应该弄清楚如何更有效地调用它们。
你可能会发现你比他们更多地打电话给他们。
特别是如果您发现许多调用都是为了创建和删除数据结构，您可能会找到更好的方法来实现这一目标。