Vâng, nó làm mọi thứ chậm lại. Và về cơ bản, nó có một hàng dữ liệu không được ghi lại, mặc dù điều đó thực sự được duy trì bởi kernel, tất cả các chương trình đều có điều đó, trừ khi chúng yêu cầu rõ ràng khác.
Ví dụ, đây là một ống tầm thường sử dụng pv, điều này rất tốt vì nó hiển thị tốc độ truyền:
$ pv -s 50g -S -pteba /dev/zero | cat > /dev/null
50GiB 0:00:09 [ 5.4GiB/s] [===============================================>] 100%
Bây giờ, hãy thêm một cái teevào đó, thậm chí không viết thêm một bản sao nữa mà chỉ chuyển tiếp nó theo:
$ pv -s 50g -S -pteba /dev/zero | tee | cat > /dev/null
50GiB 0:00:20 [2.44GiB/s] [===============================================>] 100%
Vì vậy, điều đó khá chậm một chút, và nó thậm chí không làm gì cả! Đó là chi phí chung của tee sao chép STDIN vào STDOUT. (Thật thú vị, việc thêm một giây pvvào đó vẫn ở mức 5,19GiB / giây, vì vậy pvnhanh hơn đáng kể so với tee. pvSử dụng splice(2), teecó thể không.)
Dù sao, hãy xem điều gì xảy ra nếu tôi bảo teeghi vào một tệp trên đĩa. Nó khởi động khá nhanh (~ 800MiB / giây) nhưng khi nó tiếp tục, nó tiếp tục làm chậm tốc độ xuống cuối cùng xuống ~ 100MiB / s, về cơ bản là 100% băng thông ghi đĩa. (Khởi động nhanh là do kernel lưu vào bộ đệm ghi và tốc độ ghi chậm của đĩa là kernel từ chối để bộ đệm phát triển vô hạn.)
Có vấn đề gì không?
Trên đây là một trường hợp xấu nhất. Ở trên sử dụng một đường ống để phun dữ liệu nhanh nhất có thể. Việc sử dụng trong thế giới thực duy nhất tôi có thể nghĩ như thế này là chuyển dữ liệu YUV thô đến / từ ffmpeg.
Khi bạn gửi dữ liệu với tốc độ chậm hơn (vì bạn đang xử lý chúng, v.v.), nó sẽ có tác dụng ít quan trọng hơn nhiều.