Satō Katsura'nın cevabını içgüdüsel olarak kabul ederdim; mantıklı. Ancak, test etmek kolay.
Ekrana bir milyon satır yazmayı, bir dosyaya yazmayı (ekleme) ve yönlendirmeyi test ettim /dev/null. Bunların her birini sırayla test ettim, sonra beş kopya yaptım. Bunlar benim kullandığım komutlar.
$ time (for i in {1..1000000}; do echo foo; done)
$ time (for i in {1..1000000}; do echo foo; done > /tmp/file.log)
$ time (for i in {1..1000000}; do echo foo; done > /dev/null)
Sonra aşağıdaki toplam süreleri çizdim.

Gördüğünüz gibi, Satō Katsura'nın varsayımları doğruydu. Satō Katsura'nın cevabına göre, sınırlayıcı faktörün çıktı olacağından da şüpheliyim, bu nedenle çıktı seçiminin betiğin genel hızı üzerinde önemli bir etkisi olması muhtemel değildir.
FWIW, orjinal cevabım değişik dosya koduna sahipti ve dosya döngünün içine eklenmiş ve /dev/nullyönlendirildi .
$ rm /tmp/file.log; touch /tmp/file.log; time (for i in {1..1000000}; do echo foo >> /tmp/file.log; done)
$ time (for i in {1..1000000}; do echo foo > /dev/null; done)
John Kugelman'ın yorumlarda işaret ettiği gibi, bu çok fazla ek yük getirir. Soru durduğunda, onu test etmenin doğru yolu bu değildir, ancak betiği kendi içinden tekrar tekrar açmanın maliyetini açıkça gösterdiği için burada bırakacağım .

Bu durumda, sonuçlar tersine çevrilir.