我想说明一个具体的例子,以了解在Objective-C中重写java代码时是否存在最佳(和最差)实践。
我已经将org.apache.wicket.util.diff.myers的Java实现移植到OSX Snow Leopard上的Objective-C(Xcode 4),但与Java版本相比,结果运行得非常慢。
性能最差的方法是buildPath,它主要是
Cocoa没有任何集合类可以轻松使用稀疏数组,所以我已经分配了一个带有malloc的数组,这大大改进了基于NSDictionary的第一个版本和分配用作密钥的数量的NSNumber对象。
PathNode(s)分配是使用普通语法[[MyClass alloc] init]
完成的,它们不是自动释放的,因为它们被添加到NSMutableArray中(但是在将它添加到数组后立即释放)
使用[NSArray objectAtIndex:index]完成对数组的随机访问我认为(但我可能错了)将它移动到C类并不会加速。
您是否有任何想法可以提高性能,哪里可以找到瓶颈? 使用仪器74%的时间用于分配,我该如何改善分配?
编辑我已将我的实际实施提交到github,显然是alpha版本尚未准备好投放,并且不使用任何有效的objective-c构造
答案 0 :(得分:2)
你有一个很好的开始。您已经分析了代码,隔离了实际的瓶颈,现在专注于如何解决它。
第一个问题是哪个分配成本高昂?显然你应该首先关注那个。
有几种有效的方法可以处理稀疏数组。首先,查看NSPointerArray,它旨在保存NULL值。它不承诺对稀疏数组有效,但@bbum(谁知道这些事情)suggests it is。
接下来,查看NSHashMap,这对于稀疏集合(它是字典)肯定是有效的,并且支持非对象键(即,您不需要创建NSNumber
)。 / p>
最后,如果分配确实是你的问题,有各种各样的技巧来解决它。最常见的是重用对象而不是破坏对象并创建另一个对象。这就是UITableViewCell
的工作方式(以及NSCell
以不同的方式)。
最后,如果切换到Core Foundation对象,您可以创建自己的专用内存分配器,但这确实是最后的手段。
请注意,10.6支持ARC(不归零弱引用)。 ARC大大提高了许多常见内存管理模式的性能。例如,在ARC下高度优化了“保留+自动释放+返回”这一非常常见的模式。 (ARC中的语言中不存在“retain”,但它仍然存在于编译器中,并且ARC比手动操作快得多。)我强烈建议您使用任何代码切换到ARC。
答案 1 :(得分:1)
您可以使用NSPointerArray
类替代稀疏数组。 NSPointerArray
允许null
个元素。
如果您发布产生大量分配的代码,我们可能会为您提供更多帮助。