gpt4 book ai didi

performance - NSDirectoryEnumerator 的 fileAttributes 方法的性能特征是什么?

转载 作者:行者123 更新时间:2023-12-03 16:29:17 24 4
gpt4 key购买 nike

迭代目录时调用 fileAttributes 方法的开销有多大?

特别是,我想检查正在枚举的路径是否是目录。使用 fileAttributes 字典还是文件管理器更好? (下面的例子)

NSString *path = "/User/Jack/Documents";
NSDirectoryEnumerator *dirEnum = [filemanager enumeratorAtPath:path];
NSString *file;
BOOL isDir;
while (file = [dirEnum nextObject]) {
NSLog(@"File: %@", file);
NSString * p = [path stringByAppendingPathComponent:file];
BOOL isDir1;
[[NSFileManager defaultManager] fileExistsAtPath:p isDirectory:&isDir1];
BOOL isDir2 = [[dirEnum fileAttributes] objectForKey:@"NSFileType"] == NSFileTypeDirectory;
NSLog(@"isDirectory using fileExistsAtPath:isDirectory: = %d", isDir1);
NSLog(@"isDirectory using FileAttributes = %d", isDir2);
}

fileAttributes 除了 isDirectory 之外还返回大量“不必要的”信息,这是一个示例输出

2011-12-23 16:17:40.523 App[10190:707] File Attributes: {
NSFileCreationDate = "2011-10-23 04:04:51 +0000";
NSFileExtensionHidden = 0;
NSFileGroupOwnerAccountID = 80;
NSFileGroupOwnerAccountName = admin;
NSFileModificationDate = "2011-10-23 04:07:52 +0000";
NSFileOwnerAccountID = 501;
NSFileOwnerAccountName = Tony;
NSFilePosixPermissions = 493;
NSFileReferenceCount = 6;
NSFileSize = 204;
NSFileSystemFileNumber = 8381694;
NSFileSystemNumber = 234881029;
NSFileType = NSFileTypeDirectory;
}

然而调用 fileManager 似乎也很浪费,因为我们已经枚举了有问题的目录。

有什么见解吗?

最佳答案

在大多数文件系统上,这两种方法都会花费相同的时间来检查文件是否存在并检查它是否是目录,因为除了目录条目数据之外,还需要访问 inode 数据。这相当于每个文件的“stat ”调用。

获取(完整)文件属性需要另外读取有关文件的信息。 inode 包含有关文件大小、类型等信息。每个文件属性调用可能需要额外的 IO 读取操作(此处忽略任何缓存)。

但是,HFS/HFS+ 不同。它的特殊之处在于将文件类型存储在目录条目( Source Code )中。因此,您可以检查文件是否是目录,而无需访问 inode 信息。 NSFileManager 的 fileExistsAtPath:isDirectory: 应该快得多。可能,这仅在涉及数百或数千个文件时才真正重要,但无论如何它应该更快。

顺便说一句:ext4 也是 similar feature,除非“文件类型”标志被禁用。

关于performance - NSDirectoryEnumerator 的 fileAttributes 方法的性能特征是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8620717/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com