FAT，检索文件时优化性能

我有一个数据库实现每个记录一个文件，我有大约10000条记录。我试图优化访问文件的性能，我有点怀疑。FAT，检索文件时优化性能

将文件拆分成文件夹更好，然后保存在单个文件夹中，以便快速访问文件？例如：从0到999的文件夹中0，1000年至1999年在2等等

，这是什么更好的，FAT16或FAT32？

2012-03-18 blow

@Kerrek SB：heheh，即时通讯工作在嵌入式设备上，RAM小于2KB，只有我有权访问SD卡来存储文件。 – blow 2012-03-18 10:09:44

Yr评论是Q的重要信息，而不是每个人的时间浪费在前期。你能把你的记录固定长度吗？那么如果是这样的话，使用直接记录访问的某种形式的单个文件将提供最佳性能如果键入，则使用简单的二次散列算法进行索引。 – TerryE 2012-03-18 13:02:04

如果您直接访问这些文件，则不会有任何性能下降。如果您在磁盘上搜索特定文件，将其存储在文件夹中会更快。这种方式的文件夹将模拟数据库索引。但是@blow提到，为什么不使用Sqlite之类的东西？

来源

2012-03-18 10:15:39 Davita

我没有使用sqlite或其他sql数据库的硬件要求。我只能将记录存储为文件...“如果您在磁盘上搜索特定文件”，您是什么意思？我通过文件名retive一个文件，这是搜索还是直接访问？ – blow 2012-03-18 10:17:22

@blow这是直接访问:-)。你不能担心这方面的性能问题 – Davita 2012-03-18 11:03:55

当你retrieve a file by filename你很可能会在包含该文件的目录中进行线性搜索，你会跳过所有目录条目，直到找到与给定文件名匹配的目录条目。

如果您每次为每个文件执行此操作，该搜索操作可能会很慢，目录中有许多文件，并且读取速度很慢（如果您的CPU速度较慢，则会损失更多）。

您可能想要构建某种索引，按文件名排序的紧凑型对filename+location阵列，您可以将它保留在内存中以快速查找无重读目录条目的文件。

如果文件数恒定并且长度相同或填充的长度相同，则可以大大简化事情。在这种情况下，您不需要任何搜索，因为您可以直接从文件名中计算每个文件的位置，当然，这些文件的顺序是固定的。

在这种情况下FAT1x和FAT32之间的唯一实际区别是文件分配表的大小，该链接列表/链的集合告诉你哪些集群是空闲的或被文件/目录数据占用，并告诉你哪个集群是给定之后的文件/目录中的下一个。在FAT32中，群集链元素是32位，比FAT16大2倍。如果使用的簇的数量很少（小于〜64K），那么在读FAT32时，您将读取两倍于FAT16的数据。另外，如果磁盘上有许多群集，则在FAT32上找到一个空闲群集（当您创建一个新文件/目录或增加一个现有文件时）可能会很慢（并且在FAT32 AFAIR与2^^上可能高达2^28） 16的FAT16）。您不希望每次都从FAT的开头搜索空闲群集。你想在某个地方留下一个指向你停止搜索的最后一个地方的指针，并且下一次从那里搜索，然后当你达到FAT的结尾时去到FAT的开头。

来源

2012-03-18 11:15:25

在目录之间拆分它们（拆分数量取决于您的簇大小），并且如果可以的话不要使用LFN（LongFileName），因为这会降低您的操作速度。我也致力于嵌入式系统。我不需要访问像你这样的1000个文件，但我避免了LFN（特别是出于版税原因）。

来源

2012-03-18 12:24:20 Malkocoglu

FAT，检索文件时优化性能

回答

相关问题