Das Problem der Ein-/Ausgabe-Performance ( I/O)

1. Warum ist I/O so langsam?

„Langsamkeit“ der Ein-/Ausgabe (I/O) ist eine der ewigen Fragen. Unser Code „wartet“ oft länger auf Daten, als er „denkt“. Schauen wir uns an, warum der Gang zur „Speisekammer“ langsamer ist als die Arbeit in der „Küche“.

Physikalische Beschränkungen der Hardware (Hardware Limitations)

Festplatten (HDD). Mechanik: Platten drehen sich, der Lese-/Schreibkopf bewegt sich. Es braucht Zeit für Suche (seek) und Rotation — das führt zu hoher Latenz.

Solid-State-Drives (SSD). Schneller als HDD, keine Mechanik, aber Schreiben und das Wear-Leveling machen Operationen nicht instant.

Netzwerk. Hängt von Bandbreite und Latenzen, Routern usw. ab. Selbst bei Gigabit-Leitungen sind Roundtrips zu entfernten Servern Millisekunden, nicht Nanosekunden wie die CPU.

Overhead des Betriebssystems (OS Overhead)

• Rechteprüfung. Darf der Prozess die Datei lesen/schreiben?
• Lokalisierung der Dateidaten. Das Dateisystem sammelt Fragmentblöcke.
• Buffering und Cache. Das OS verwaltet Puffer für Effizienz.
• Context-Switching. Solange der Prozess auf I/O wartet, wechselt die CPU den Kontext — das kostet ebenfalls Zeit.

Die große Kluft: CPU-Geschwindigkeit vs. I/O-Geschwindigkeit

• CPU-Operation: 0.2 – 0.5 Nanosekunden
• Lesen aus RAM: 10 – 100 Nanosekunden
• Lesen von SSD: 50 – 100 Mikrosekunden
• Lesen von HDD: 5 – 10 Millisekunden
• Netzwerkrequest: 10 – 100 Millisekunden und mehr

Die Lücke ist riesig. Wenn du für jeden Buchstaben einen „Botendienst“ rufst (I/O), wirst du langsam tippen, egal wie schnell dein „Schreiber“ (CPU) ist. Viel effizienter ist es, Daten in Blöcken zu holen — Sätzen und Absätzen.

2. Innerhalb einer Datei: was passiert wirklich?

Die Befehlskette beim Arbeiten mit einer Datei sieht so aus:

flowchart TD
    A[Dein C#-Code] --> B[.NET FileStream]
    B --> C[OS Windows / Linux / Mac]
    C --> D[Dateisystem: NTFS, ext4, APFS]
    D --> E[Treibermodul]
    E --> F[Physisches Laufwerk: HDD / SSD]

• Dein Code ruft z.B. File.ReadAllText(path) auf.
• .NET verwendet unter der Haube FileStream, Buffer und System Calls.
• OS verwaltet Caching und Queues.
• Dateisystem findet die Datenblöcke der Datei.
• Treiber kommuniziert mit dem Gerät.
• Das Laufwerk führt die physische Operation aus.

Jede Schicht fügt Overhead hinzu. Der Engpass ist meistens das physische Medium.

3. Beispiel: langsamer Code in der Praxis

Anti‑Pattern: eine Datei byteweise mit ReadByte() lesen.

// ❌ Ineffizientes byteweises Lesen der Datei
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
int currentByte;
while ((currentByte = fs.ReadByte()) != -1)
{
    // Mach etwas mit dem Byte
}

Warum ist das schlecht? Jeder Aufruf von ReadByte() ist ein separater Stream-Zugriff. Bei großen Dateien sind das Millionen von Aufrufen, und das System verbrät Zeit mit Overhead statt mit nützlicher Arbeit.

Richtig ist blockweises Lesen:

// ✅ Effizientes Lesen der Datei in großen Blöcken
byte[] buffer = new byte[4096]; // 4 KB — Standardpuffergröße
int bytesRead;
using FileStream fs = new FileStream("bigfile.txt", FileMode.Open);
while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
{
    // Verarbeite den erhaltenen Datenblock
}

Das Lesen in größeren Stücken erlaubt OS und Laufwerk, Cache und Queues effizienter zu nutzen — die Laufzeit fällt um ein Vielfaches.

4. Auswirkung auf reale Anwendungen

Benutzeroberfläche (UI). Blockierendes I/O „friert“ das Fenster ein. Wichtig ist, I/O in Hintergrund/Asynchronität auszulagern und den Hauptthread nicht zu blockieren.

Webserver und DBs. Server lesen und schreiben ständig; eine langsame Festplatte oder Netzwerk verlangsamt den ganzen Dienst. Buffering, Connection Pools und asynchrones I/O sind der Schlüssel zur Durchsatzsteigerung.

Big Data. Bei Gigabytes/Terabytes skaliert jede Ineffizienz. Blockgrößen, sequentieller Zugriff und Streaming-Processing sind entscheidend.

Spiele. Lange Ladezeiten von Levels/Assets sind I/O. Richtiges Packaging der Assets und das Lesen in großen Chunks reduzieren Ladezeiten.

5. Typische Fehler von Einsteigern

Ein häufiger Fehler ist zeilenweises oder byteweises Lesen großer Dateien mit ReadByte oder einem zu kleinen Buffer (z.B. 256 Bytes). Die Anzahl der System Calls steigt und die Performance fällt.

Es gibt auch das andere Extrem: versuchen, eine riesige Datei komplett mit File.ReadAllBytes zu laden — und die erwartete OutOfMemoryException. Besser ist die goldene Mitte: sinnvolle Blockgrößen (häufig 4–8 KB und mehr, je nach Workload) und Streaming-Verarbeitung.