Buffered I/O: Batch System Calls for Speed

Why it exists

System calls, like writing to a disk or network, are expensive operations. They require the operating system to switch from user mode to kernel mode, which incurs significant overhead. If your application writes data one byte or one line at a time, it pays this performance penalty on every single write. Buffered I/O exists to drastically reduce the number of these costly system calls.

The mental model

Think of buffered I/O like a shipping department. Instead of dispatching a delivery truck for every single package that's ready, the department collects packages in a loading area (the buffer). Only when the loading area is full, or after a certain time, is one truck (the system call) sent out with all the packages. This is far more efficient than sending one truck per package.

How it works

When your application writes data, it goes into a temporary, in-memory array called a buffer, not directly to the disk. This operation returns almost instantly. The I/O library tracks how full the buffer is. Once the buffer is full, the library performs a single, large system call to write the entire buffer's contents to the destination. The buffer is then cleared and the process repeats. You can also manually "flush" the buffer to force a write before it is full, which is crucial to ensure data is not lost if the program exits.

When to use it

Use buffered I/O whenever you perform many small, sequential read or write operations. This is extremely common in file processing (reading or writing line-by-line), network communication (sending small messages), and logging. Some languages, like Go, use it by default for file I/O. Others, like Rust, require you to explicitly wrap your I/O handle in a buffered type like BufWriter or BufReader to get this performance benefit.

When not to use it

Avoid buffered I/O when you need immediate, guaranteed durability for every single write, such as in a database transaction log where each commit must be confirmed on disk. For very large, single-chunk writes, a buffer adds little value and just consumes extra memory, as you're already performing an efficient, large write. It is also less effective for random-access I/O patterns where data is read or written at arbitrary, non-sequential locations in a file.

One canonical example

A performance test in Rust writing 100,000 lines to a file shows the dramatic difference. A naive loop using writeln! directly on a File handle results in over 300,000 write system calls and takes several seconds. By simply wrapping the File handle in a BufWriter, the number of system calls plummets, and the operation completes in milliseconds. The BufWriter collects the lines in its internal buffer and writes them to the file in large, infrequent chunks, avoiding the massive system call overhead.