Saya akan setuju secara naluriah dengan jawaban Satō Katsura; masuk akal. Namun, itu cukup mudah untuk diuji.
Saya diuji menulis sejuta baris ke layar, menulis (menambahkan) ke file, dan mengarahkan ke /dev/null
. Saya menguji masing-masing pada gilirannya, kemudian melakukan lima ulangan. Ini adalah perintah yang saya gunakan.
$ 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)
Saya kemudian merencanakan total waktu di bawah ini.
Seperti yang Anda lihat, anggapan Satō Katsura benar. Sesuai jawaban Satō Katsura, saya juga ragu bahwa faktor pembatasnya adalah output, jadi tidak mungkin pilihan output akan memiliki efek besar pada kecepatan keseluruhan skrip.
FWIW, jawaban asli saya memiliki kode yang berbeda, yang memiliki file yang ditambahkan dan /dev/null
dialihkan di dalam loop.
$ 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)
Seperti yang ditunjukkan oleh John Kugelman dalam komentar, ini menambah banyak biaya tambahan. Seperti pertanyaannya, ini sebenarnya bukan cara yang tepat untuk mengujinya, tetapi saya akan meninggalkannya di sini karena jelas menunjukkan biaya membuka kembali file berulang kali dari dalam skrip itu sendiri.
Dalam hal ini, hasilnya terbalik.