如果我将 Objective-C 用于低级代码，我的 iPhone 应用程序会降低性能吗？

Will my iPhone app take a performance hit if I use Objective-C for low level code?

提问by slf

When programming a CPU intensive or GPU intensive application on the iPhone or other portable hardware, you have to make wise algorithmic decisions to make your code fast.

在 iPhone 或其他便携式硬件上编写 CPU 密集型或 GPU 密集型应用程序时，您必须做出明智的算法决策以加快代码速度。

But even great algorithm choices can be slow if the language you're using performs more poorly than another.

但是，如果您使用的语言的性能比另一种语言更差，那么即使是出色的算法选择也会很慢。

Is there any hard data comparing Objective-C to C++, specifically on the iPhone but maybe just on the Mac desktop, for performance of various similar language aspects? I am very familiar with this article comparing C and Objective-C, but this is a larger question of comparing two object oriented languages to each other.

是否有任何硬数据将 Objective-C 与 C++ 进行比较，特别是在 iPhone 上，但可能只是在 Mac 桌面上，以获取各种类似语言方面的性能？我非常熟悉这篇比较 C 和 Objective-C 的文章，但这是比较两种面向对象语言的更大问题。

For example, is a C++ vtable lookup really faster than an Obj-C message? How much faster? Threading, polymorphism, sorting, etc. Before I go on a quest to build a project with duplicate object models and various test code, I want to know if anybody has already done this and what the results where. This type of testing and comparison is a project in and of itself and can take a considerable amount of time. Maybe this isn't one project, but two and only the outputs can be compared.

例如，C++ vtable 查找真的比 Obj-C 消息快吗？快多少？线程、多态、排序等。在我继续使用重复的对象模型和各种测试代码构建项目之前，我想知道是否有人已经这样做了，结果在哪里。这种类型的测试和比较本身就是一个项目，可能需要相当长的时间。也许这不是一个项目，而是两个并且只有输出可以比较。

I'm looking for hard data, not evangelism. Like many of you I love and hate both languages for various reasons. Furthermore, if there is someone out there actively pursuing this same thing I'd be interesting in pitching in some code to see the end results, and I'm sure others would help out too. My guess is that they both have strengths and weaknesses, my goal is to find out precisely what they are so that they can be avoided/exploited in real-world scenarios.

我正在寻找硬数据，而不是传福音。像你们中的许多人一样，出于各种原因，我又爱又恨这两种语言。此外，如果有人积极追求同样的事情，我会很有趣地投入一些代码以查看最终结果，我相信其他人也会提供帮助。我的猜测是它们都有优点和缺点，我的目标是准确地找出它们是什么，以便在现实世界中避免/利用它们。

采纳答案by Brad Larson

Mike Ash has some hard numbers for performance of various Objective-C method calls versus C and C++ in his post "Performance Comparisons of Common Operations". Also, this postby Savoy Software is an interesting read when it comes to tuning the performance of an iPhone application by using Objective-C++.

Mike Ash 在他的文章“常见操作的性能比较”中给出了各种 Objective-C 方法调用与 C 和 C++ 的性能对比。此外， 在使用 Objective-C++ 调整 iPhone 应用程序的性能方面，Savoy Software 的这篇文章很有趣。

I tend to prefer the clean, descriptive syntax of Objective-C over Objective-C++, and have not found the language itself to be the source of my performance bottlenecks. I even tend to do things that I know sacrifice a little bit of performance if they make my code much more maintainable.

与 Objective-C++ 相比，我更喜欢 Objective-C 的简洁、描述性的语法，并且没有发现语言本身是我的性能瓶颈的根源。我什至倾向于做一些我知道会牺牲一点性能的事情，如果它们使我的代码更易于维护。

回答by justin

Yes, well written C++ is considerably faster. If you're writing performance critical programs and your C++ is not as fast as C (or within a few percent), something's wrong. If your ObjC implementation is as fast as C, then something's usuallywrong -- i.e. the program is likely a bad example of ObjC OOD because it probably uses some 'dirty' tricks to step below the abstraction layer it is operating within, such as direct ivar accesses.

是的，写得好的 C++ 速度要快得多。如果您正在编写性能关键的程序，而您的 C++ 没有 C 快（或在几个百分点内），那么一定有问题。如果您的 ObjC 实现与 C 一样快，那么通常会有问题——即该程序可能是 ObjC OOD 的一个坏例子，因为它可能使用了一些“肮脏”的技巧来踩到它正在运行的抽象层之下，例如直接ivar 访问。

The Mike Ash 'comparison' is very misleading -- I would never recommend the approach to compare execution times of programs you have written, or recommend it to compare C vs C++ vs ObjC. The results presented are provided from a test with compiler optimizations disabled. A program compiled with optimizations disabled is rarely relevant when you are measuring execution times. To view it as a benchmark which compares C++ against Objective-C is flawed. The test also compares individual features, rather than entire, real world optimized implementations -- individual features are combined in very different ways with both languages. This is far from a realistic performance benchmark for optimized implementations. Examples: With optimizations enabled, IMPcache is as slow as virtual function calls. Static dispatch (as opposed to dynamic dispatch, e.g. using virtual) and calls to known C++ types (where dynamic dispatch may be bypassed) may be optimized aggressively. This process is called devirtualization, and when it is used, a member function which is declared virtualmay even be inlined. In the case of the Mike Ash test where many calls are made to member functions which have been declared virtualand have empty bodies: these calls are optimized away entirelywhen the type is known because the compiler sees the implementation and is able to determine dynamic dispatch is unnecessary. The compiler can also eliminate calls to mallocin optimized builds (favoring stack storage). So, enabling compiler optimizations in any of C, C++, or Objective-C can produce dramatic differences in execution times.

Mike Ash 的“比较”非常具有误导性——我永远不会推荐这种方法来比较您编写的程序的执行时间，或者推荐它来比较 C 与 C++ 与 ObjC。显示的结果是从禁用编译器优化的测试中提供的。当您测量执行时间时，在禁用优化的情况下编译的程序很少相关。将其视为将 C++ 与 Objective-C 进行比较的基准是有缺陷的。该测试还比较了单独的功能，而不是整个现实世界的优化实现——单独的功能以非常不同的方式与两种语言相结合。这远不是优化实现的现实性能基准。示例：启用优化后，IMP缓存和虚函数调用一样慢。静态分派（与动态分派相反，例如使用virtual）和对已知 C++ 类型的调用（其中动态分派可能被绕过）可以被积极地优化。这个过程称为去虚拟化，使用时，声明的成员函数virtual甚至可能是inlined。在 Mike Ash 测试的情况下，其中对已声明且具virtual有空主体的成员函数进行了多次调用：当类型已知时，这些调用将被完全优化掉，因为编译器会看到实现并能够确定动态分派是不必要。编译器还可以消除对malloc在优化的构建中（有利于堆栈存储）。因此，在任何 C、C++ 或 Objective-C 中启用编译器优化都会在执行时间上产生巨大的差异。

That's not to say the presented results are entirely useless. You could get some useful information about external APIs if you want to determine if there are measurable differences between the times they spend in pthread_createor +[NSObject alloc]on one platform or architecture versus another. Of course, these two examples will be using optimized implementations in your test (unless you happen to be developing them). But for comparing one language to another in programs you compile… the presented results are useless with optimizations disabled.

这并不是说所呈现的结果完全没有用。如果您想确定外部 API在一个平台或架构中pthread_create或+[NSObject alloc]在一个平台或架构上花费的时间与另一个之间是否存在可测量的差异，您可以获得一些关于外部 API 的有用信息。当然，这两个示例将在您的测试中使用优化的实现（除非您碰巧正在开发它们）。但是为了在你编译的程序中将一种语言与另一种语言进行比较……所呈现的结果在禁用优化的情况下毫无用处。

Object Creation

对象创建

Consider also object creation in ObjC - every object is allocated dynamically (e.g. on the heap). With C++, objects may be created on the stack (e.g. approximately as fast as creating a C struct and calling a simple function in many cases), on the heap, or as elements of abstract data types. Each time you allocate and free (e.g. via malloc/free), you may introduce a lock. When you create a C struct or C++ object on the stack, no lock is required (although interior members may use heap allocations) and it often costs just a few instructions or a few instructions plus a function call.

还要考虑在 ObjC 中创建对象——每个对象都是动态分配的（例如在堆上）。使用 C++，对象可以在堆栈上创建（例如，在许多情况下大约与创建 C 结构和调用简单函数一样快）、在堆上或作为抽象数据类型的元素创建。每次分配和释放（例如通过 malloc/free）时，您可能会引入一个锁。当您在堆栈上创建 C 结构或 C++ 对象时，不需要锁定（尽管内部成员可能使用堆分配）并且通常只需要几条指令或几条指令加上一个函数调用。

As well, ObjC objects are reference counted instances. The actual need for an object to be a std::shared_ptrin performance critical C++ is very rare. It's not necessary or desirable in C++ to make every instance a shared, reference counted instance. You have much more control over ownership and lifetime with C++.

同样，ObjC 对象是引用计数的实例。对象成为std::shared_ptr性能关键 C++的实际需求非常罕见。在 C++ 中，让每个实例都成为共享的、引用计数的实例是不必要的或不可取的。使用 C++，您可以更好地控制所有权和生命周期。

Arrays and Collections

数组和集合

Arrays and many collections in C and C++ also use strongly typed containers and contiguous memory. Since the address of the next element's members are often known, the optimizer can do much more, and you have great cache and memory locality. With ObjC, that's far from reality for standard objects (e.g. NSObject).

C 和 C++ 中的数组和许多集合也使用强类型容器和连续内存。由于下一个元素成员的地址通常是已知的，优化器可以做更多的事情，并且您有很好的缓存和内存局部性。使用 ObjC，这对于标准对象（例如NSObject）来说远非现实。

Dispatch

派遣

Regarding methods, many C++ implementations use few virtual/dynamic calls, particularly in highly optimized programs. These are static method calls and fodder for the optimizers.

关于方法，许多 C++ 实现很少使用虚拟/动态调用，特别是在高度优化的程序中。这些是优化器的静态方法调用和素材。

With ObjC methods, each method call (objc message send) is dynamic, and is consequently a firewall for the optimizer. Ultimately, that results in many restrictions or inconveniences regarding what you can and cannot do to keep performance at a minimum when writing performance critical ObjC. This may result in larger methods, IMP caching, frequent use of C.

使用 ObjC 方法，每个方法调用（objc 消息发送）都是动态的，因此是优化器的防火墙。最终，这会导致在编写性能关键的 ObjC 时，您可以做什么和不可以做什么来将性能保持在最低水平，从而导致许多限制或不便。这可能会导致更大的方法、IMP 缓存、频繁使用 C。

Some realtime applications cannot use anyObjC messaging in their render paths. None -- audio rendering is a good example of this. ObjC dispatch is simply not designed for realtime purposes; Allocations and locks may happen behind the scenes when messaging objects, making the complexity/time of objc messaging unpredictable enough that the audio rendering may miss its deadline.

某些实时应用程序无法在其渲染路径中使用任何ObjC 消息传递。无——音频渲染就是一个很好的例子。ObjC 调度根本不是为实时目的而设计的；传递对象时，分配和锁定可能会在幕后发生，这使得 objc 消息传递的复杂性/时间不可预测，以至于音频渲染可能会错过其最后期限。

Other Features

其他特性

C++ also provides generics/template implementations for many of its libraries. These optimize very well. They are typesafe, and a lot of inlining and optimizations may be made with templates (consider it polymorphism, optimization, and specialization which takes place at compilation). C++ adds several features which just are not available or comparable in strict ObjC. Trying to directly compare langs, objects, and libraries which are very different is not so useful -- it's a very small subset of actual realizations. It's better to expand the question to a library/framework or real program, considering many aspects of design and implementation.

C++ 还为其许多库提供泛型/模板实现。这些优化得很好。它们是类型安全的，并且可以使用模板进行许多内联和优化（考虑它在编译时发生的多态性、优化和专业化）。C++ 添加了一些在严格的 ObjC 中不可用或无法比较的特性。试图直接比较非常不同的语言、对象和库并不是很有用——它是实际实现的一个非常小的子集。考虑到设计和实现的许多方面，最好将问题扩展到库/框架或实际程序。

Other Points

其他要点

C and C++ symbols can be more easily removed and optimized away in various stages of the build (stripping, dead code elimination, inlining and early inlining, as well as Link Time Optimization). The benefits of this include reduced binary sizes, reduced launch/load times, reduced memory consumption, etc.. For a single app, that may not be such a big deal; but if you reuse a lot of code, and you should, then your shared libraries could add a lot of unnecessary weight to the program, if implemented ObjC -- unless you are prepared to jump through some flaming hoops. So scalability and reuse are also factors in medium/large projects, and groups where reuse is high.

在构建的各个阶段（剥离、死代码消除、内联和早期内联，以及链接时间优化），C 和 C++ 符号可以更容易地删除和优化。这样做的好处包括减少二进制文件大小、减少启动/加载时间、减少内存消耗等。对于单个应用程序来说，这可能不是什么大问题；但是如果你重用了很多代码，而且你应该重用，那么你的共享库可能会给程序增加很多不必要的重量，如果实现了 ObjC —— 除非你准备跳过一些燃烧的箍。因此，可扩展性和重用也是中/大型项目和重用率高的组的因素。

Included Libraries

包含的库

ObjC library implementors also optimize for the environment, so its library implementors can make use of some language and environment features to offer optimized implementations. Although there are some pretty significant restrictions when writing an optimized program in pure ObjC, some highly optimized implementations exist in Cocoa. This is one of Cocoa's strong points, although the C++ standard library (what some people call the STL) is no slouch either. Cocoa operates at a much higher level of abstraction than C++ -- if you don't know well what you're doing (or should be doing), operating closer to the metal can really cost you. Falling back on to a good library implementation if you are not an expert in some domain is a good thing, unless you are really prepared to learn. As well, Cocoa's environments are limited; you can find implementations/optimizations which make better use of the OS.

ObjC 库实现者也针对环境进行了优化，因此其库实现者可以利用一些语言和环境特性来提供优化的实现。尽管在纯 ObjC 中编写优化程序时有一些非常重要的限制，但 Cocoa 中存在一些高度优化的实现。这是 Cocoa 的强项之一，尽管 C++ 标准库（有些人称之为 STL）也毫不逊色。Cocoa 在比 C++ 更高的抽象层次上运行——如果你不太清楚你在做什么（或应该做什么），那么靠近金属运行真的会让你付出代价. 如果您不是某个领域的专家，那么回到一个好的库实现是一件好事，除非您真的准备好学习。同样，Cocoa 的环境也是有限的。您可以找到更好地利用操作系统的实现/优化。

If you're writing optimized programs and have experience doing so in both C++ and ObjC, cleanC++ implementations will often be twice as fast or faster than cleanObjC (yes, you can compare against Cocoa). If you know how to optimize, you can often do better than higher level, general purpose abstractions. Although, some optimized C++ implementations will be as fast as or slower than Cocoa's (e.g. my initial attempt at file I/O was slower than Cocoa's -- primarily because the C++ implementation initializes its memory).

如果您正在编写优化程序并且在 C++ 和 ObjC 中都有这样做的经验，那么干净的C++ 实现通常会比干净的ObjC快两倍或更快（是的，您可以与 Cocoa 进行比较）。如果您知道如何优化，通常可以比更高级别的通用抽象做得更好。虽然，一些优化的 C++ 实现将与 Cocoa 的实现一样快或更慢（例如，我对文件 I/O 的初始尝试比 Cocoa 的慢——主要是因为 C++ 实现初始化了它的内存）。

A lot of it comes down to the language features you are familiar with. I use both langs, they both have different strengths and models/patterns. They complement each other quite well, and there are great libraries for both. If you're implementing a complex, performance critical program, correct use of C++'s features and libraries will give you much more control and provide significant advantages for optimization, such that in the right hands, "several times faster" is a good default expectation (don't expect to win every time, or without some work, however). Remember, it takes years to understand C++ well enough to really reach that point.

很多都归结为您熟悉的语言功能。我使用两种语言，它们都有不同的优势和模型/模式。它们相得益彰，两者都有很棒的库。如果你正在实现一个复杂的、性能关键的程序，正确使用 C++ 的特性和库会给你更多的控制，并为优化提供显着的优势，这样在正确的人手中，“快几倍”是一个很好的默认期望（但是，不要期望每次都赢，或者不做一些工作）。请记住，要充分理解 C++ 才能真正达到这一点，需要数年时间。

I keep the majority of my performance critical paths as C++, but also recognize that ObjC is also a very good solution for some problems, and that there are some very good libraries available.

我将大部分性能关键路径保留为 C++，但也认识到 ObjC 也是一些问题的非常好的解决方案，并且有一些非常好的库可用。

回答by Johan Kotlinski

It's very hard to collect "hard data" for this that's not misguiding.

为此收集“硬数据”是非常困难的，而且不会产生误导。

The biggest problem with doing a feature-to-feature comparison like you suggest is that the two languages encourage very different coding styles. Objective-C is a dynamic language with duck typing, where typical C++ usage is static. The same object-oriented architecture problem would likely have very different ideal solutions using C++ or Objective-C.

像您建议的那样进行功能间比较的最大问题是这两种语言鼓励非常不同的编码风格。Objective-C 是一种带有鸭子类型的动态语言，其中典型的 C++ 用法是静态的。相同的面向对象架构问题使用 C++ 或 Objective-C 可能会有非常不同的理想解决方案。

My feeling (as I have programmed much in both languages, mostly on huge projects): To maximize Objective-C performance, it has to be written very close to C. Whereas with C++, it's possible to make much more use of the language without any performance penalty compared to C.

我的感觉（因为我用两种语言编写了很多程序，主要是在大型项目中）：为了最大限度地提高 Objective-C 的性能，它必须非常接近 C。而使用 C++，可以在没有与 C 相比的任何性能损失。

Which one is better? I don't know. For pure performance, C++ will always have the edge. But the OOP style of Objective-C definitely has its merits. I definitely think it is easier to keep a sane architecture with it.

哪一个更好？我不知道。对于纯粹的性能，C++ 将始终具有优势。但是Objective-C的OOP风格绝对有它的优点。我绝对认为用它保持一个健全的架构更容易。

回答by Grant Peters

This really isn't something that can be answered in general as it really depends on how you use the language features. Both languages will have things that they are fast at, things that they are slow at, and things that are sometimes fast and sometimes slow. It really depends on what you use and how you use it. The only way to be certain is to profile your code.

这确实不是一般可以回答的问题，因为它实际上取决于您如何使用语言功能。这两种语言都会有他们擅长的事情，他们擅长的事情，以及有时快有时慢的事情。这实际上取决于您使用什么以及如何使用它。唯一确定的方法是分析您的代码。

In Objective C you can also write c++ code, so it might be easier to code in Objective C for the most part, and if you find something that doesn't perform well in it, then you can have a go at writting a c++ version of it and seeing if that helps (C++ tends to optimize better at compile time). Objective C will be easier to use if APIs you are interfacing with are also written in it, plus you might find it's style of OOP is easier or more flexible.

在 Objective C 中，您也可以编写 c++ 代码，因此在大多数情况下使用 Objective C 进行编码可能会更容易，如果您发现某些内容在其中表现不佳，那么您可以尝试编写 c++ 版本看看它是否有帮助（C++ 往往在编译时优化得更好）。如果您所连接的 API 也是用 Objective C 编写的，那么它会更容易使用，而且您可能会发现它的 OOP 风格更简单或更灵活。

In the end, you should go with what you know you can write safe, robust code in and if you find an area that needs special attention from the other language, then you can swap to that. X-Code does allow you to compile both in the same project.

最后，您应该使用您所知道的可以编写安全、健壮的代码，如果您发现某个区域需要其他语言特别注意，那么您可以切换到该区域。X-Code 确实允许您在同一个项目中编译两者。

回答by memo

I have a couple of tests I did on an iPhone 3G almost 2 years ago, there was no documentation or hard numbers around in those days. Not sure how valid they still are but the source code is posted and attached.

大约 2 年前，我在 iPhone 3G 上进行了几次测试，当时没有文档或硬性数字。不确定它们仍然有效，但已发布并附加了源代码。

This isn't a very extensive test, I was mainly interested in NSArray vs C Array for iterating a large number of objects.

这不是一个非常广泛的测试，我主要对 NSArray 与 C Array 的迭代大量对象感兴趣。

http://memo.tv/nsarray_vs_c_array_performance_comparison

http://memo.tv/nsarray_vs_c_array_performance_comparison

http://memo.tv/nsarray_vs_c_array_performance_comparison_part_ii_makeobjectsperformselector

http://memo.tv/nsarray_vs_c_array_performance_comparison_part_ii_makeobjectsperformselector

You can see the C Array is much faster at high iterations. Since then I've realized that the bottleneck is probably not the iteration of the NSArray but the sending of the message. I wanted to try methodForSelector and calling the methods directly to see how big the difference would be but never got round to it. According to Mike Ash's benchmarks it's just over 5x faster.

您可以看到 C 数组在高迭代时要快得多。从那时起，我意识到瓶颈可能不是 NSArray 的迭代，而是消息的发送。我想尝试 methodForSelector 并直接调用方法以查看差异有多大，但从未考虑过。根据 Mike Ash 的基准测试，它的速度提高了 5 倍多一点。

回答by aalok

I don't have hard data for Objective C, but I do have a good place to look for C++.

我没有关于 Objective C 的硬数据，但我确实有一个寻找 C++ 的好地方。

C++ started as C with Classes according to Bjarne Stroustroup in his reflection on the early years of C++ (http://www2.research.att.com/~bs/hopl2.pdf), so C++ can be thought of (like Objective C) as pushing C to its limits for object orientation.

根据 Bjarne Stroustroup 在他对 C++ 早期的反思 ( http://www2.research.att.com/~bs/hopl2.pdf) 中，C++ 是从带有类的 C 开始的，所以 C++ 可以被认为是（如 Objective C ) 将 C 推向面向对象的极限。

What are those limits? In the 1994-1997 time frame, a lot of researchers figured out that object-orientation came at a cost due to dynamic binding, e.g. when C++ functions are marked virtual and there may/may not be children classes that override these functions. (In Java and C#, all functions expect ctors are inherently virtual, and there isnt' much you can do about it.) In "A Study of Devirtualization Techniques for a Java Just-In-Time Compiler" from researchers at IBM Research Tokyo, they contrast the techniques used to deal with this, including one from Urz H?lzle and Gerald Aigner. Urz H?lzle, in a separate paper with Karel Driesen, had shown that on average 5.7% of time in C++ programs (and up to ~50%) was spent in calling virtual functions (e.g. vtables + thunks). He later worked with some Smalltalk researachers in what ended up the Java HotSpot VM to solve these problems in OO. Some of these features are being backported to C++ (e.g. 'protected' and Exception handling).

这些限制是什么？在 1994-1997 年的时间范围内，许多研究人员发现，由于动态绑定，面向对象是有代价的，例如，当 C++ 函数被标记为 virtual 并且可能/可能没有覆盖这些函数的子类时。（在 Java 和 C# 中，所有期望 ctors 的函数本质上都是虚拟的，对此您无能为力。）在 IBM Research Tokyo 研究人员的“Java 即时编译器的去虚拟化技术研究”中，他们对比了用于处理此问题的技术，包括来自 Urz H?lzle 和 Gerald Aigner 的技术。Urz H?lzle 在与 Karel Driesen 合作的另一篇论文中表明，在 C++ 程序中平均有 5.7% 的时间（高达约 50%）用于调用虚函数（例如 vtables + thunk）。后来他与一些 Smalltalk 研究人员一起工作，最终开发了 Java HotSpot VM，以解决 OO 中的这些问题。其中一些功能正在向后移植到 C++（例如“受保护”和异常处理）。

As I mentioned, C++ is static typed where Objective C is duck typed. The performance difference in execution (but not lines of code) probably is a result of this difference.

正如我所提到的，C++ 是静态类型的，而 Objective C 是鸭子类型的。执行中的性能差异（但不是代码行）可能是这种差异的结果。

回答by bobobobo

This studysays to really get the performance in a CPU intensive game, you have to use C. The linked article is complete with a XCode project that you can run.

这项研究表明，要真正在 CPU 密集型游戏中获得性能，您必须使用 C。链接文章中包含一个可以运行的 XCode 项目。

I believe the bottom lineis: Use Objective-C where you must interact with the iPhone's functions (after all, putting trampolines everywhere can't be good for anyone), but when it comes to loops, things like vector object classes, or intensive array access, stick with C++ STL or C arrays to get good performance.

我相信底线是：在必须与 iPhone 的功能交互的地方使用 Objective-C（毕竟，把蹦床放在任何地方对任何人都不好），但是当涉及到循环时，像向量对象类或密集型数组访问，坚持使用 C++ STL 或 C 数组以获得良好的性能。

I mean it would be totally silly to see position = [[Vector3 alloc] init] ;. You're just asking for a performance hit if you use references counts on basic objects like a position vector.

我的意思是看到position = [[Vector3 alloc] init] ;. 如果您在基本对象（如位置向量）上使用引用计数，那么您只是要求性能下降。

回答by jimmy

yes. c++ reign supreme in performance/expresiveness/resource tradeoff.

是的。c++ 在性能/表达能力/资源权衡方面占据主导地位。

"I'm looking for hard data, not evangelism". google is your best friend.

“我正在寻找硬数据，而不是传福音”。谷歌是你最好的朋友。

1. obj-c nsstring is swapped with c++'s by apple enginneers for performance. in a resource constrained devices, only c++ cuts it as a MAINSTREAM oop language. NSString stringWithFormat is slow

2. obj-c oop abstraction is deconstructed into procedural-based c-structs for performance, otherwise a MAGNITUDE order slower than java! the author is also aware of message caching - yet no-go. so modeling lots of small players/enemies objects is done in oop with c++ or else, lots of Procedural structs with a simple OOP wrapper around it with obj-c. there can be one paradigm that equates Procedural + Object-Oriented Programming = obj-c. http://ejourneyman.wordpress.com/2008/04/23/writing-a-ray-tracer-for-cocoa-objective-c/

1. 为了提高性能，苹果工程师将 obj-c nsstring 与 c++ 交换。在资源受限的设备中，只有 c++ 将其切割为 MAINSTREAM oop 语言。 NSString stringWithFormat 很慢

2. obj-c oop 抽象被解构为基于过程的 c 结构以提高性能，否则 MAGNITUDE 顺序比 java! 作者也知道消息缓存 - 但没有去。因此，对许多小型玩家/敌人对象进行建模是在使用 c++ 的 oop 中完成的，或者使用 obj-c 在其周围使用简单的 OOP 包装器对许多程序结构进行建模。可以有一种范式将过程 + 面向对象编程 = obj-c。 http://ejourneyman.wordpress.com/2008/04/23/writing-a-ray-tracer-for-cocoa-objective-c/