0

我不知道我在这方面是对还是错，但根据常识，command file会比or稍微快一点。command dir/filecommand dir1/.../dirN/file

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

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

现在我问我的问题：

  • 有没有可能获得性能提升？
  • 如果是这样，如何对其进行基准测试？
  • 如果可以进行基准测试，一个目录中必须有多少文件才能在进出它的时间上达到平衡cd？
  • 这也会影响 Java、PHP、Python 等的文件操作吗？
4

2 回答 2

1

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

于 2013-03-10T07:10:26.927 回答
1

有没有可能获得性能提升？

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

stat *: 真实 - 8m 47.112s
cd ...: 真实 - 8m 47.475s
stat dir/dir/dir/*: 真实 - 9m 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 目录：2,500
2 目录：1,250
3 目录：1,000

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

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

于 2013-03-10T22:04:23.497 回答