Problema de rendimiento de entrada/salida ( I/O)

1. ¿Por qué I/O es tan lento?

La "lentitud" de entrada/salida (I/O) es una de esas preguntas eternas. Nuestro código a menudo "espera" los datos más tiempo del que "piensa". Vamos a ver por qué las visitas al "almacén" son lentas comparadas con el trabajo en la "cocina".

Limitaciones físicas del hardware (Hardware Limitations)

Discos duros (HDD). Mecánica: los platos giran, la cabeza se mueve. Hace falta tiempo para el desplazamiento (seek time) y la rotación — eso da una alta latencia.

Unidades de estado sólido (SSD). Más rápidos que los HDD, sin partes mecánicas, pero la escritura y la gestión del desgaste de las celdas hacen que las operaciones no sean instantáneas.

Red. Depende del ancho de banda y la latencia, routers, etc. Incluso con un enlace gigabit, la respuesta de un servidor remoto son milisegundos, no nanosegundos como la CPU.

Sobrehead del sistema operativo (OS Overhead)

• Comprobación de permisos. ¿Puede el proceso leer/escribir ese archivo?
• Localización de los datos del archivo. El sistema de ficheros reúne los fragmentos.
• Buffering y caché. El SO gestiona buffers para ser eficiente.
• Cambio de contexto. Mientras el proceso espera I/O, la CPU hace switches — eso también cuesta tiempo.

La gran división: velocidad de la CPU vs. velocidad de I/O

• Operación de CPU: 0.2 – 0.5 nanosegundos
• Lectura desde RAM: 10 – 100 nanosegundos
• Lectura desde SSD: 50 – 100 microsegundos
• Lectura desde HDD: 5 – 10 milisegundos
• Solicitud de red: 10 – 100 milisegundos o más

La brecha es enorme. Si "llamas al mensajero" por cada letra (I/O), vas a escribir lento sin importar lo rápido que sea tu "mecanógrafo" (CPU). Es mucho más eficiente traer los datos en bloques — frases y párrafos.

2. Dentro del archivo: ¿qué pasa realmente?

La cadena de comandos al trabajar con un archivo se ve así:

flowchart TD
    A[Tu código C#] --> B[.NET FileStream]
    B --> C[Sistema operativo: Windows / Linux / Mac]
    C --> D[Sistema de ficheros: NTFS, ext4, APFS]
    D --> E[Driver del dispositivo]
    E --> F[Dispositivo físico: HDD / SSD]

• Tu código llama, por ejemplo, a File.ReadAllText(path).
• .NET bajo el capó usa FileStream, buffers y llamadas al sistema.
• El SO gestiona caché y colas.
• El sistema de ficheros localiza los bloques de datos del archivo.
• El driver se comunica con el dispositivo.
• El almacenamiento realiza la operación física.

Cada capa añade sobrecarga. El cuello de botella suele ser el soporte físico.

3. Ejemplo: código lento en la práctica

Anti-pattern: leer el archivo byte a byte usando ReadByte().

// ❌ Lectura ineficiente del archivo por bytes
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
int currentByte;
while ((currentByte = fs.ReadByte()) != -1)
{
    // Hacemos algo con el byte
}

¿Por qué es malo? Cada llamada a ReadByte() es una interacción separada con el stream. En archivos grandes hay millones de esas llamadas, y el sistema gasta tiempo en overhead en lugar de trabajo útil.

La forma correcta es leer por bloques:

// ✅ Lectura eficiente del archivo en bloques grandes
byte[] buffer = new byte[4096]; // 4 KB — tamaño estándar de buffer
int bytesRead;
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
{
    // Procesamos el bloque de datos recibido
}

Leer en porciones grandes permite al SO y al disco usar la caché y las colas de forma más eficiente — el tiempo de ejecución disminuye por órdenes de magnitud.

4. Impacto en aplicaciones reales

Interfaz de usuario (UI). Un I/O bloqueante "congela" la ventana. Es importante mover operaciones a fondo/usar asincronía y no bloquear el hilo principal.

Servidores web y BD. Los servidores leen/escriben datos constantemente; un disco lento o la red ralentizan todo el servicio. Buffering, pools de conexiones y I/O asíncrono son clave para la throughput.

Big Data. Con gigas/terabytes cualquier ineficiencia se escala. Tamaño de bloques, acceso secuencial y procesamiento en streaming suelen decidir el resultado.

Juegos. Cargas largas de niveles/recursos son I/O. Empaquetar assets correctamente y leer en chunks grandes reduce tiempos de carga.

5. Errores típicos de principiantes

Un error común es leer líneas o bytes uno por uno en archivos grandes usando ReadByte o un buffer demasiado pequeño (por ejemplo, 256 bytes). El número de llamadas al sistema crece y el rendimiento cae.

También existe el extremo opuesto: intentar leer un archivo gigantesco completo con File.ReadAllBytes — y el esperado OutOfMemoryException. Mejor buscar un "punto medio razonable": bloques sensatos (a menudo 4–8 KB o más, según el perfil de carga) y procesamiento en streaming.