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？

回答

相關問題