Objective c 目标C与C速度
这可能是一个幼稚的问题，但我还是要问 我正在iOS上使用Core Audio（C API），并将C与Objective-C混合使用。我的类有.mm扩展名，到目前为止一切都正常 我在不同的地方读到过关于Objective-C速度慢的文章（没有给出太多细节，我也没有做出任何声明）。我了解不从核心音频渲染回调调用Objective-C等，以及原因 另一方面，我需要从GUI调用处理核心音频内容的类，以便在运行时进行各种调整。会有一些阵列的移动，主要是移动核心音频使用的数据。在速度方面，用C编写函数并将变量存储在向量而不是NSMutableArray中会有什么好处Objective c 目标C与C速度,objective-c,c,ios,Objective C,C,Ios,这可能是一个幼稚的问题，但我还是要问 我正在iOS上使用Core Audio（C API），并将C与Objective-C混合使用。我的类有.mm扩展名，到目前为止一切都正常 我在不同的地方读到过关于Objective-C速度慢的文章（没有给出太多细节，我也没有做出任何声明）。我了解不从核心音频渲染回调调用Objective-C等，以及原因 另一方面，我需要从GUI调用处理核心音频内容的类，以便在运行时进行各种调整。会有一些阵列的移动，主要是移动核心音频使用的数据。在速度方面，用C编写函数并将变
我在Objective-C/iOS上只工作了几个月，所以对此我没有任何看法。Objective-C并不慢，它实际上是带有对象的C Objective-C中的一个类由几个不同的内容组成：
- 选择器到函数的映射（方法实现）
- 名称到类型（实例变量）的映射
- 类型和函数（属性）的名称映射
因此，Objective-C的速度与自己调用原始C函数的速度差不多，查找函数时会有一点开销。Objective-C比直接的C函数调用稍慢，因为它的动态特性涉及到查找。如果以后没有其他人添加详细信息，我将编辑这个答案，并详细说明它是如何工作的 然而，更重要的是，您过早地进行了优化。Objective-C的额外开销很有可能对应用程序的性能没有显著影响
利用Objective-C的优势，尽可能设计出编写得最好、最面向对象的应用程序。如果且仅当测试显示性能问题时，优化应用程序的这些特定区域。Objective-C的主要性能影响在于分派方法调用所需的工作。Objective-C是动态绑定的，这意味着接收消息的对象（选择器）决定在运行时如何处理它。这是通过哈希表实现的。选择器是散列的（我认为是在编译时），并映射到通过散列表调用的方法，查找需要时间 话虽如此，在
objc_msgSend（）NSArray-objectAtIndex:对于处理核心音频原始样本，请坚持使用C。对于处理与UI相关的核心音频事件（停止、启动、属性等），将它们封装在Objective C中不会产生任何可测量的速度差异。Objective C与C一样快速 因为没有Objective C编译器，所有Objective C代码都使用结构和函数指针解析为C。 Objective C是我们用C编写面向对象编程的方式。面向对象编程语言（Objective C中的Small Talk）的所有特性都是用C编写的。 实际上，我们可以通过使用结构（可以有类的实例变量）和相关函数操作数据来定义C中的对象。消息传递或调用对象函数是通过使用
objc_msgSend(receiver,selector,arg1,arg2....)
也就是C，目标C处理器给出了目标C。当我们编译目标C代码时，它被转换成纯C，C代码被编译并运行。C和目标C之间的区别是速度。< P>而其他答案已经量化了，动态方法调度（ObjcIsMgStand）是手工调谐的汇编，增加了大约20个机器指令，与C相比，Objtovi-C中另一个可能的性能较差的原因：Objtovi-C有一个更丰富的基础库。p> 其中一个性能比较有一个生成游戏的地形，如下所示：
- 纯C版本的速度为60 fps
- objective-C版本的速度为39 fps
幸运的是，正如其他人所说，以后进行性能分析并在一些纯C代码中进行交换非常容易，因为这些代码将被计算在内 这完全取决于你在做什么。使用核心音频，99%的执行时间无论如何都应该花在库函数上。现在，如果您做了一些愚蠢的事情—获取第二个样本，将每个样本转换为NSNumber，将它们存储到NSMutableArray，并使用[[myArray objectAtIndex:i]doubleValue]调用手工编写FFT，您将得到应得的结果。速度最慢的iPhone每微秒可以进行相当多的方法调用 无论您使用的是C函数还是Objective-C方法