IO操作 - 为什么不cd？

我不知道自己对这个是对还是错，但是根据常识，command file应该是咯快于command dir/file或者command dir1/.../dirN/file。IO操作 - 为什么不cd？

现在，假设这是真的，让我们考虑一下脚本和命令，这些脚本和命令涉及处理大量目录中的大量文件（例如编译你的gentoo内核）。如果脚本或程序足够聪明，可以将它们存储到包含大量文件的目录中，是否会有性能提升？

在我看来，从不再遵循这些指针数百次或数千次所节省的时间可能会弥补光盘进入和退出目录所花费的时间。

现在我问我的问题：

是否有性能提升的可能性？
如果是这样，它怎么可以基准？
如果可以进行基准测试，那么即使在cd花费的时间内，还需要在一个目录中有多少个文件才能打破？
这也会影响Java，PHP，Python等文件操作吗？

来源

2013-03-10 Chat Tor

至于cd'ng进入目录来处理文件...'make'已经做到了。只是说。 :) – cHao 2013-03-10 06:54:22

我不知道。似乎我不是唯一一个想知道这一点的人。 – 2013-03-10 06:56:51

“command file'会比'command dir/file'稍微快一些” - [WAT？]（https://www.destroyallsoftware.com/talks/wat） – 2013-03-10 07:03:56

性能增益有没有可能？

数：10,000,000（50000个文件，循环200次）

stat *：真正的 - 8米47.112s
cd ...：真正的 - 8米47.475s
stat dir/dir/dir/*：真正的 - 9米33.609s

如果是这样，那么它如何进行基准测试？

我用下面的命令为我的测试：

mkdir dir; 
mkdir dir/dir; 
mkdir dir/dir/dir; 
cd dir/dir/dir; 
touch $(seq 1 50000); 
time for i in $(seq 1 200); do stat * > /dev/null; done; 
cd ../../../; 
time for i in $(seq 1 200); do stat dir/dir/dir/* > /dev/null; done; 
time $(cd dir/dir/dir; for i in $(seq 1 200); do stat * > /dev/null; done; cd ../../../);

如果基准-能，许多文件将如何必须在目录中盈亏平衡的时间花在CD和出来的？

这是不可能确切地知道数字而没有其他进程运行的专用系统，但它看起来像“收支平衡”的数字似乎是：

1 DIR：2,500
2 DIR 1,250
3 dir：1,000

这也会影响Java，PHP，Python等文件操作吗？

使用常识，我认为路径会添加这个微小的时间差异，但唯一真正的解决方案，我能想到的是将所有包含的文件放在1个目录中，使一个单独的包含文件包含所有包含的内容，并在运行时代码中包含“大容量包装器”。

来源

2013-03-10 22:04:23

如果你做了一个chdir，你可以在目录上查找并创建一个dentry。之后对dir/file的调用应该已经具有dir的dentry。同样，如果你对dir/file1和dir/file2 .... dir/fileN进行访问，查找应该只对dir发生一次。因此我怀疑是否有性能上的提升。 'Make'可能会出于其他原因做chdir。

来源

2013-03-10 07:10:26 user1952500

我觉得这样的东西已经到位了，但是有什么办法可以测量这种性能差异？ – 2013-03-10 07:28:48

您可以有一个查找程序。你可以尝试运行'stat'作为你的命令，因为你并不是真的想要数据操作来歪曲你的结果。您可能想要统计几百万个文件来标准化结果。 – user1952500 2013-03-10 07:33:07

另请查看Postmark [http://www.fsl.cs.sunysb.edu/docs/auto-pilot/Postmark.html]的具体信息 – user1952500 2013-03-10 08:32:07

IO操作 - 为什么不cd？

回答

相关问题