使用本地化标准比较对 NSURL 进行排序的性能答案

【问题标题】：Performance of sorting NSURLs with localizedStandardCompare使用本地化标准比较对 NSURL 进行排序的性能
【发布时间】：2013-01-22 21:09:16
【问题描述】：

我需要使用本地化标准比较对包含 NSURL 的 NSMutableArray 进行排序：

[array sortUsingComparator:^NSComparisonResult(id obj1, id obj2) {
    NSString *f1 = [(NSURL *)obj1 absoluteString];
    NSString *f2 = [(NSURL *)obj2 absoluteString];
    return [f1 localizedStandardCompare:f2];
}];

这很好用，但我有点担心性能：在排序过程中，块将被评估 n log n 次，所以我希望它快（数组可能有多达 100,000 个元素）。由于localizedStandardCompare 仅在NSString 上可用，我需要将URL 转换为字符串。上面，我使用absoluteString，但还有其他方法返回一个NSString，例如relativeString。阅读 NSURL 类参考，我觉得 relativeString 可能更快，因为不需要解析 URL，但这是我第一次使用 Cocoa 和 OS-X，因此只是一个疯狂的猜测。

附加约束：在这种情况下，所有 URL 都来自本地存储上的 NSDirectoryEnumerator，因此都是文件 URL。不过，如果该方法适用于所有类型的 URL，那将是一个好处。

我的问题：我应该使用哪种方法将 NSURL 转换为 NSString 以获得最佳性能？

分析所有可能的方法可能是可能的，但我只有一台（相当快的）OS-X 机器，谁知道 - 有一天代码可能最终会出现在 iOS 上。

我在 OS-X 10.8.2 上使用 Xcode 4.5.2，但该程序也应该在旧版本上运行（在合理范围内）。

【问题讨论】：

标签： objective-c performance macos cocoa

【解决方案1】：

您可能需要使用 Carbon 的 FSCatalogSearch，它比 NSDirectoryEnumerator 更快。至于获得路径，我认为别无选择。

您可以考虑加快排序的唯一事情是路径是部分排序的，因为文件系统将按字母顺序返回同一文件夹中的所有文件。

因此您可能希望获取同一目录的所有路径并将它们与其他结果合并。

例如首页内容可能是：

ab1.txt
bb.txt
c.txt

文档目录可能包含：

adf.txt
fgh.txt

因此，您只需使用自定义算法将它们合并，该算法仅应用合并排序的合并部分。

【讨论】：

您对按字母顺序返回的文件有参考吗？这不取决于文件系统吗？（请注意，排序仍然是必要的，因为localizedStandardCompare 不是按字母顺序排列的，但是对于几乎排序的输入，例如合并排序可能仍然要快得多）。
FSCatalogSearch 似乎在 10.8 中已被弃用，所以我想避免使用它。
对不起，我没有任何参考资料，我只是试了一下，我的系统按字母顺序返回文件。是的，这取决于文件系统，但我们都使用 OS X，不确定版本。
我使用的是 10.8.2，但“本地存储”也可能是 FAT32 或 NTFS 卷，或者 OS-X 可以挂载的任何其他卷。

【解决方案2】：

我对排序进行了基准测试。事实证明，absoluteString 和 relativeString 比 path 或 relativePath 快得多。

对大约 26000 个条目进行排序：

relativeString      550ms
absoluteString      580ms
path                920ms
relativePath        960ms
field access        480ms

对于字段访问，我在排序之前将absoluteString 的值放入一个字段并访问该字段。因此，...String 访问器几乎与字段访问一样快，因此对于我的用例来说是一个不错的选择。

【讨论】：