Vấn đề hiệu năng nhập-xuất ( I/O)

1. Tại sao I/O lại chậm thế?

“Tốc độ chậm” của nhập-xuất (I/O) là một trong những câu hỏi muôn thuở. Mã của chúng ta thường “đợi” dữ liệu lâu hơn là “nghĩ”. Hãy cùng phân tích vì sao việc đi tới "kho" (storage) chậm hơn làm việc trên "bếp" (CPU).

Giới hạn vật lý của phần cứng (Hardware Limitations)

Ổ đĩa cơ (HDD). Cơ học: đĩa quay, đầu đọc/ghi di chuyển. Cần thời gian di chuyển (seek time) và quay — điều này tạo ra độ trễ cao.

Ổ trạng thái rắn (SSD). Nhanh hơn HDD, không có cơ học, nhưng việc ghi và quản lý wear-leveling làm cho các thao tác không phải lúc nào cũng tức thì.

Mạng. Phụ thuộc băng thông và độ trễ, router, v.v. Dù có kết nối gigabit, phản hồi từ server từ xa là mili giây, chứ không phải nano giây như CPU.

Chi phí phụ của hệ điều hành (OS Overhead)

• Kiểm tra quyền truy cập. Quy trình có quyền đọc/ghi file không?
• Tìm dữ liệu của file. File system phải lắp các mảnh lại với nhau.
• Buffering và cache. OS quản lý bộ đệm để tối ưu hiệu năng.
• Context switch. Khi process chờ I/O, CPU chuyển ngữ cảnh — điều này cũng tốn thời gian.

Sự khác biệt lớn: tốc độ CPU vs. tốc độ I/O

• Thao tác CPU: 0.2 – 0.5 nanô giây
• Đọc từ RAM: 10 – 100 nanô giây
• Đọc từ SSD: 50 – 100 micro giây
• Đọc từ HDD: 5 – 10 mili giây
• Yêu cầu mạng: 10 – 100 mili giây trở lên

Khoảng cách là khổng lồ. Nếu bạn "gọi shipper" cho từng ký tự (I/O), bạn sẽ gõ rất chậm dù "bàn phím" (CPU) nhanh đến đâu. Hiệu quả hơn nhiều là lấy dữ liệu theo khối — câu và đoạn.

2. Bên trong file: thực sự xảy ra gì?

Chuỗi lệnh khi làm việc với file trông như sau:

flowchart TD
    A[Mã C# của bạn] --> B[.NET FileStream]
    B --> C[Hệ điều hành Windows / Linux / Mac]
    C --> D[File system: NTFS, ext4, APFS]
    D --> E[Driver thiết bị]
    E --> F[Thiết bị vật lý: HDD / SSD]

• Mã của bạn gọi ví dụ File.ReadAllText(path).
• .NET phía dưới dùng FileStream, buffer và system calls.
• OS quản lý cache và hàng đợi.
• File system tìm các block dữ liệu của file.
• Driver giao tiếp với thiết bị.
• Thiết bị lưu trữ thực hiện thao tác vật lý.

Mỗi tầng thêm chi phí phụ. Cổ chai thường ở lớp thiết bị vật lý.

3. Ví dụ: mã chậm trong thực tế

Anti-pattern: đọc file từng byte bằng ReadByte().

// ❌ Đọc file theo byte không hiệu quả
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
int currentByte;
while ((currentByte = fs.ReadByte()) != -1)
{
    // Làm gì đó với byte
}

Tại sao xấu? Mỗi lần gọi ReadByte() là một truy vấn vào stream. Với file lớn số lần gọi có thể là hàng triệu, và hệ thống tốn thời gian cho overhead thay vì làm việc hữu ích.

Đúng cách — đọc theo khối:

// ✅ Đọc file hiệu quả theo khối lớn
byte[] buffer = new byte[4096]; // 4 KB — kích thước buffer tiêu chuẩn
int bytesRead;
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
{
    // Xử lý khối dữ liệu nhận được
}

Đọc theo phần lớn cho phép OS và đĩa tận dụng tốt hơn cache và hàng đợi — thời gian chạy giảm nhiều lần.

4. Ảnh hưởng tới ứng dụng thực tế

Giao diện người dùng (UI). I/O blocking làm "đóng băng" cửa sổ. Quan trọng là đẩy các thao tác ra background/async và không block main thread.

Web server và DB. Servers liên tục đọc/ghi; đĩa chậm hoặc mạng chậm làm dịch vụ yếu đi. Buffering, connection pool và asynchronous I/O là chìa khóa cho throughput.

Big Data. Với gigabyte/terabyte, mọi inefficiency sẽ nhân lên. Kích thước khối, truy cập tuần tự và streaming xử lý quyết định kết quả.

Game. Tải level/asset chậm là vấn đề I/O. Đóng gói asset hợp lý và đọc theo chunk lớn giảm thời gian load.

5. Lỗi thường gặp của người mới

Lỗi phổ biến — đọc file theo dòng hoặc theo byte dùng ReadByte hoặc dùng buffer quá nhỏ (ví dụ 256 byte). Số system call tăng, hiệu năng giảm.

Có cực đoan ngược lại: cố đọc toàn bộ file lớn bằng File.ReadAllBytes — và nhận OutOfMemoryException. Tốt hơn là chọn "vừa phải": khối hợp lý (thường 4–8 KB hoặc lớn hơn tùy profile) và xử lý theo luồng.