在我的程序中，我使用的是file.open（path_to_file）;
在服务器端，我有一个包含大量文件的目录，如果由于file.open（）目录越来越大，我担心程序运行的时间会更长;
//code:
ofstream file;
file.open("/mnt/srv/links/154");//154 is the link id and in directory /mnt/srv/links i have plenty of files
//write to file
file.close();
问题：可以根据目录中的文件数量来确定执行文件的时间吗？
我使用的是debian，我相信我的文件系统是ext3。
答案 0 :(得分：2)
我会尝试回答这个问题 - 然而，这很难，因为它依赖于，例如：
使用什么文件系统 - 在某些文件系统中，目录由未排序的文件列表组成，在这种情况下，查找特定文件的时间是O（n） - 因此对于900000个文件，它将是一个要搜索的长列表。另一方面，其他一些使用散列算法或排序列表，分别允许O（1）和O（log2（n）） - 当然，必须单独找到目录的每个部分。使用900k的数量，O（n）比O（1）慢900000倍，而900k的O（log2（n））不到20，因此18000次＆＃34;更快＆＃34;。但是，对于900k文件，即使是二进制搜索也可能需要做一些事情，因为如果我们的每个目录条目的大小为100字节[1]，我们就会谈论85MB的目录数据。所以即使我们只触及19或20个不同的地方，也会有几个部门要读。
文件本身的位置 - 位于我自己的硬盘上的文件比我在德克萨斯州奥斯汀的同事的文件服务器上的文件要快得多，当我＆＃39 ;在英格兰。
所涉及的任何文件服务器和通信链接的负载 - 当然，如果我是唯一使用NFS或SAMBA服务器的设备，它会更快而不是使用服务于2000台机器的集群的文件服务器，这些机器都忙于请求文件。
包含文件的系统上的内存量和总内存使用量，和/或本地计算机中可用的内存量。大多数现代操作系统将在本地具有文件缓存，如果您使用的是服务器，则服务器上也会有文件缓存。更多记忆 - ＆gt;更多空间来缓存东西 - ＆gt;更快捷的访问。特别是，它可以很好地缓存目录结构和内容。
本地计算机的整体性能。虽然几乎所有上述因素都很重要，但搜索文件的简单工作可能足以对大量文件产生一些影响 - 特别是如果搜索是线性的。
[1]目录条目至少包含：
这是66个字节。但我觉得100字节可能更典型。
答案 1 :(得分：1)
是的，它可以。这完全取决于文件系统，而不是语言。打开/读取/写入/关闭文件的时间都由相应系统调用的时间决定。 C ++应该增加相对较少的开销，即使你可以从C ++实现中获得惊喜。
答案 2 :(得分：0)
有很多变量可能影响答案，但一般的答案是文件数量会影响打开文件所需的时间。
最大的变量是使用的文件系统。现代文件系统使用目录索引结构（例如B-Trees）来允许搜索已知文件是相对快速的操作。另一方面，列出目录中的所有文件或使用通配符搜索子集可能需要更长的时间。
其他因素包括：
根据我的经验，使用现代文件系统，单个文件可以位于包含数千个文件的目录中，时间不到一秒。