The I/O performance problem ( I/O)

1. Why is I/O so slow?

"I/O slowness" (I/O) is one of those perennial questions. Our code often "waits" for data longer than it "thinks". Let's break down why trips to the "pantry" are slow compared to working on the "kitchen" counter.

Hardware Limitations

Hard disk drives (HDD). Mechanics: platters spin, the head moves. You need time for seeking and rotation — that gives high latency.

Solid state drives (SSD). Faster than HDD, no mechanics, but writes and wear-leveling make operations non-instant.

Network. Depends on bandwidth and latency, routers, etc. Even with a gigabit link, a round trip to a remote server is milliseconds, not nanoseconds like the CPU.

OS Overhead

• Permission checks. Can the process read/write the file?
• Locating the file's data. The file system assembles fragments.
• Buffering and caching. The OS manages buffers for efficiency.
• Context switches. While the process waits for I/O, the CPU switches — that costs time too.

The big split: CPU speed vs I/O speed

• CPU operation: 0.2 – 0.5 nanoseconds
• RAM read: 10 – 100 nanoseconds
• SSD read: 50 – 100 microseconds
• HDD read: 5 – 10 milliseconds
• Network request: 10 – 100 milliseconds and up

The gap is massive. If you "call the courier" for every letter (I/O), you'll type slowly no matter how fast your "typist" (CPU) is. It's far more efficient to fetch data in chunks — sentences and paragraphs.

2. Inside a file: what actually happens?

The chain of commands when working with a file looks like this:

flowchart TD
    A[Your C# code] --> B[.NET FileStream]
    B --> C[OS Windows / Linux / Mac]
    C --> D[File system: NTFS, ext4, APFS]
    D --> E[Device driver]
    E --> F[Physical storage: HDD / SSD]

• Your code calls, for example, File.ReadAllText(path).
• .NET under the hood uses FileStream, buffers and system calls.
• The OS manages caching and queues.
• The file system finds the file's data blocks.
• The driver talks to the device.
• The storage performs the physical operation.

Each layer adds overhead. The bottleneck is most often the physical medium.

3. Example: slow code in practice

Anti-pattern: reading a file one byte at a time using ReadByte().

// ❌ Inefficient byte-by-byte file reading
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
int currentByte;
while ((currentByte = fs.ReadByte()) != -1)
{
    // Do something with the byte
}

Why is this bad? Every ReadByte() call is a separate stream access. For large files there are millions of such calls, and the system spends time on overhead instead of useful work.

Right approach — read in blocks:

// ✅ Efficient reading of a file in large blocks
byte[] buffer = new byte[4096]; // 4 KB — a standard buffer size
int bytesRead;
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
{
    // Process the received block of data
}

Reading in larger chunks lets the OS and disk use cache and queues more effectively — execution time drops by orders of magnitude.

4. Impact on real applications

User interface (UI). Blocking I/O will "freeze" the window. It's important to move operations to background/asynchronous tasks and avoid blocking the main thread.

Web servers and databases. Servers constantly read/write data; a slow disk or network slows the whole service. Buffering, connection pools and asynchronous I/O are key to throughput.

Big Data. With gigabytes/terabytes any inefficiency scales. Block size, sequential access and streaming processing are decisive.

Games. Long level/resource loading is an I/O problem. Proper asset packing and reading in big chunks reduce load times.

5. Common beginner mistakes

A frequent mistake is line-by-line or byte-by-byte reading of large files via ReadByte or using too small a buffer (for example, 256 bytes). System call counts rise and performance drops.

There is the opposite extreme too: trying to read a huge file entirely with File.ReadAllBytes — and the expected OutOfMemoryException. Better to choose a "golden middle": reasonable chunks (often 4–8 KB and up, depending on workload profile) and streaming processing.