The slower process limits the speed of the faster process. A pipe is a buffer (IIRC around 1kbyte in size) between a process that's putting bytes into the buffer with write() calls, and another process that's pulling bytes out of the buffer with read() calls.

Both the write() and read() calls pass control to the kernel. So if the reading process calls read() on an empty pipe buffer, the kernel won't return from the read() until the other process puts bytes in (or closes its stdout file descriptor). At the other end, if the writing process calls write() on a full pipe buffer, the kernel won't add the new bytes to the buffer and return from the write() until the other process pulls bytes out (or closes its stdin file descriptor).

So the effect is that the faster process's performance is constrained by the performance of the slower process. The kernel doesn't allow the pipe buffer to overflow, nor to underflow.

The slower process limits the speed of the faster process. A pipe is a buffer (512 to 64k bytes in size, depending on the kernel and any adjustments by the process using fcntl(2) operations) between a process that's putting bytes into the buffer with write() calls, and another process that's pulling bytes out of the buffer with read() calls.

Both the write() and read() calls pass control to the kernel. So if the reading process calls read() on an empty pipe buffer, the kernel won't return from the read() until the other process puts bytes in (or closes its stdout file descriptor). At the other end, if the writing process calls write() on a full pipe buffer, the kernel won't add the new bytes to the buffer and return from the write() until the other process pulls bytes out (or closes its stdin file descriptor).

So the effect is that the faster process's performance is constrained by the performance of the slower process. The kernel doesn't allow the pipe buffer to overflow, nor to underflow.