cocoa - Java代码移植到Objective-C非常慢

Question

我想通过一个具体的例子来了解在 Objective-C 中重写 java 代码时是否存在最佳(和最差)实践。

我已经移植了 org.apache.wicket.util.diff.myers 的 Java 实现在 OSX Snow Leopard (Xcode 4) 上运行 Objective-C，但结果与 Java 版本相比运行速度非常慢。

性能最差的方法是buildPath，它主要是

• 稀疏数组访问(对角变量，该数组在方法内部分配且不返回)
• 随机数组访问(orig 和 rev 变量)
• PathNode及其子类的分配(具有三个属性的对象，只有属性是数组内部使用的元素)
• 字符串比较

Cocoa 没有任何集合类可以轻松地处理稀疏数组，因此我使用 malloc 分配了一个数组，这极大地改进了基于 NSDictionary 的第一个版本以及分配用作键的无数 NSNumber 对象。

PathNode(s) 分配是使用正常语法 [[MyClass alloc] init] 完成的，它们不会自动释放，因为它们被添加到 NSMutableArray 中(但在添加到 NSMutableArray 后立即释放)数组)

对数组的随机访问是使用 [NSArray objectAtIndex:index] 完成的，我认为(但我可能是错的)将其移动到类似 C 语言并不会加速太多。

您有什么想法可以提高性能，在哪里可以找到瓶颈？使用工具74%的时间都花在分配上，如何改进分配？

编辑我已将实际实现提交给 github ，显然是一个尚未准备好投入生产的 alpha 版本，并且没有使用任何有效的 Objective-C 构造

Answer 1

你有了一个良好的开端。您已经分析了代码，隔离了实际瓶颈，现在专注于如何解决它。

第一个问题是哪种分配成本较高？显然，您应该首先关注这一点。

有几种有效的方法来处理稀疏数组。首先看NSPointerArray ，它被设计为保存 NULL 值。它不保证对稀疏数组有效，但是@bbum(谁知道这些事情)suggests it is .

接下来看NSHashMap ，这对于稀疏集合(它是一个字典)来说肯定是有效的，并且支持非对象键(即您不需要创建 NSNumber)。

最后，如果分配确实是您的问题，有多种技巧可以解决它。最常见的是重用对象，而不是销毁一个对象并创建另一个对象。这就是 UITableViewCell 的工作原理(以及 NSCell 以不同的方式)。

最后，如果您切换到 Core Foundation 对象，您可以创建自己的专用内存分配器，但这确实是最后的手段。

请注意，10.6 支持 ARC(无需将弱引用清零)。 ARC 显着提高了许多常见内存管理模式的性能。例如，非常常见的“retain+autorelease+return”模式在ARC下得到了高度优化。 (“retain”在 ARC 的语言中不存在，但它仍然存在于编译器中，而且 ARC 比手动执行要快得多。)我强烈建议您在任何代码中都切换到 ARC。