核心基础与基础
在 iPhone 开发中，速度至关重要。有谁知道使用 CoreFoundation 类型（如 CFMutableDictionaryRef）与 Foundation 类型（其对应的 NSMutableDictionary）之间是否存在速度差异。
我认为操作 CF 类型会更快，因为它不必抛出 ObjC 运行时消息，这是一个毫无根据的假设，有人真正研究过这个吗？
In iPhone development, speed is of the essence. Does anyone know if there is a speed difference between using a CoreFoundation type (like CFMutableDictionaryRef) versus a Foundation type (its counterpart, NSMutableDictionary).
I would think manipulating the CF type would be faster as it doesnt have to throw around ObjC runtime messages, is this an unfounded assumption, has anyone actually looked in to this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术意义上来说，是的，它更快，正是因为这个原因。
从实际意义上来说，不，它并没有更快。一方面，速度差异很小。我们谈论的是在整个过程的生命周期中节省的毫秒数。
iPhone 上的节省可能更大，但这仍然是你能获得的最小的速度提升。您最好将时间花在 Instruments 中分析您的应用程序，然后按照它告诉您的地方进行操作，并消除您自己代码中的热点。
这就是 Foundation 变得更快的地方：您的时间。
在可行的情况下使用 Foundation 的自动释放功能的代码可以避免容易避免的内存泄漏（即忘记写入或无法到达
release消息），从而为您节省大量时间和麻烦。 CF 没有自动释放功能，因此您必须记住显式CFRelease您使用它创建或复制的所有内容 - 当您忘记或无法到达该代码时（我的意思是当——我是根据经验说的），你将花费更多的时间来寻找内存泄漏。静态分析器有所帮助，但它永远无法捕获所有内容。（从技术上讲，您可以自动释放CF对象，但是这样做的代码非常丑陋，而且您只会削弱已经微乎其微的速度增益。）
因此，请尽可能坚持使用Foundation。不要过度使用自动释放；即使在纯 Cocoa 中，有时仍然需要显式释放对象（主要是紧密循环），对于 Cocoa Touch 来说，这种情况会加倍（因为如果分配太多内存，iOS 会杀死您的应用程序，因此您需要释放大的内存）尽快像图像这样的对象）。但通常情况下，自动释放为您节省的时间比 CF 为您的用户节省的时间多得多。
与时间无关的原因是，参数名称（来自消息选择器）与值混合的 Objective-C 代码比基于 C 函数的代码更容易阅读。这可能不会让你的工作进展得更快，但肯定会让它变得更有趣。
In a technical sense, yes, it is faster, for exactly that reason.
In a practical sense, no, it's not faster. For one thing, the speed difference is tiny. We're talking milliseconds saved over the life of the entire process.
The savings might be bigger on the iPhone, but it's still pretty much the tiniest speed gain you can get. Your time is much better spent profiling your app in Instruments and going where it tells you and ironing out the hot spots in your own code.
And that's where Foundation becomes faster: Your time.
Code that uses Foundation's autorelease feature whenever feasible saves you a lot of time and headaches by avoiding easily-avoidable memory leaks (namely, forgetting to write or failing to reach
releasemessages). CF does not have autorelease, so you have to remember to explicitlyCFReleaseeverything you create or copy with it—and when you forget or fail to reach that code (and I do mean when—I speak from experience), you will spend much more time hunting down the memory leak. The static analyzer helps, but it will never be able to catch everything.(You technically can autorelease CF objects, but the code to do so is terribly ugly and you're only watering down your already-minuscule speed gain.)
So, stick to Foundation as much as possible. Don't go overboard with the autorelease; even in pure Cocoa, there are still times when explicitly releasing objects is warranted (mostly tight loops), and this goes double for Cocoa Touch (since iOS will kill your app if you allocate too much memory, so you'll want to release big objects like images as soon as possible). But usually, autorelease saves you far more time than CF will ever save your users.
The non-time-related reason is that Objective-C code, with argument names (from the message selector) mixed in with values, is far easier to read than C function-based code. This may not make your work go any faster, but it certainly makes it more fun.
在 CF 函数中编写代码确实可能会给您的应用程序带来性能提升，但是如果您真的想要最终的性能提升，您可以简单地直接在机器代码中编写代码，它不会比这更快。尽管这将是一种极端的方法。
至少出于 Peter Hosey 提到的原因，高级语言结构比低级语言结构更可取。为此，我们可以添加过早的优化，这很容易导致项目失败，因为开发人员更关心应用程序的非功能方面而不是功能方面。
如果在拥有功能齐全的应用程序后，您觉得代码的某些部分存在性能瓶颈，则可以尝试通过将它们重写为低级语言结构来优化它们。您至少会与当前代码有一个比较点，以确保低级代码的行为符合预期（手动或单元测试都可以解决问题）。
我想说的是，虽然我们不应该忽视性能，但我们也不应该把它作为我们的首要目标。功能方面也很重要（甚至更重要）。如果您没有提供其功能规格的应用程序，那么它可能是地球上最快的应用程序，但人们仍然不会使用它。
Writing code in CF functions might indeed bring a performance boost to your app, however if you really want the ultimate performance boost, you could be simply writing code directly in machine code, it can't get any faster than that. Though this would be an extreme approach.
High-level language constructs are preferable to the low-level ones for at least the reasons Peter Hosey mentioned. To this we can add the premature optimization which can easily lead to the failure of the project, as the developer is more concerned with the non-functional aspects of the application instead of the functional ones.
If, after you have a fully functional app, you feel that some parts of the code have performance bottlenecks, you can try to optimize those, by rewriting them to low-level language constructs. You'll at least have a comparison point with the current code, to make sure the low-level code behaves as expected (either manual or unit tests will do the trick here).
What I'm trying to say is that while we should not ignore performace, we should not make this our first goal. Functional aspects are as well as important (of not even more). If you don't have an app that delivers it's functional specifications, then it might be the fastest on the planet, and people will still not be using it.