Wozu Caches da sind ...

Ein Kollege beharrte einmal darauf, dass eine Datenbankstruktur für die Bedürfnisse der eingesetzten Datenbank abgeändert werden müssen, weil die Performance beim Lesen sehr gering ausfiel.
Konkret ging es um eine Tabelle, die Kunden beinhaltete und die eigentlichen Daten waren mit dieser verkettet.

Es stellte sich heraus, dass bei jeder Anfrage zuerst der gewählte Kunde gesuchte wurde und danach mit dessen ID die weiteren Daten geladen wurden. … Und das geschah unzählige Male für jede Form der Datenbeschaffung.

Mein Vorschlag:

Wieso speichert ihr euch nicht zumindest die Kunden-ID bei der ersten Abfrage und nutzt sie dann direkt?

wurde mit seltsamen Ausreden abgelehnt. Immer wurde auf die Datenbank selbst verwiesen, die mit anderen Abfragen (Queries) schneller läuft.

… für mich klang das eher nach Ich weiß nicht wie. … also ändern wir lieber alle Datenformate ab und brechen die Kompatibilität …

Zurück zu DOS.

Der CACHE (das wird KÄSCH ausgesprochen, nicht KÄITSCH liebe Kollegen!) ist ein Speicher, der häufig benutzte Daten schnell bereitstellen kann.

Auf meinem alten 80486 hatte man im BIOS noch die Möglichkeit die CPU Caches abzuschalten. …
WOW, denn mit deaktiviertem Cache, brauchte alles, von DOS bis Windows die 3 bis 4-fache Zeit um zu starten und zu laufen.
Der CPU-Cachespeicher läuft dabei gleichschnell wie die CPU oder zumindest wesentlich schneller, als die verbauten RAM-Chips und spiegelt die aktuell bearbeiteten Speicherseiten das RAMs. Die CPU kann so wesentlich schneller ihre Aufgaben erfüllen, während sie ohne Cache nach einer Anfrage oft warten muss, bis die Daten aus dem RAM in ihre Register übertragen werden.

SMARTDRV war ein DOS Tool, welches Lesevorgänge um ein vielfaches beschleunigen konnte. Es setzte einen Disk-Cache im Speicher auf und ließ Daten beim Öffnen einer Datei in größeren Blöcken in den Speicher lesen, noch bevor das Programm sie anforderte.
Programme lesen oft in kleinen ineffizienten Bröckchen ihre Daten, was viel Zeit kostet. Dieser Disk-Cache optimiert das weg, in dem er Lesezugriffe reduziert und dafür ein paar Kilobyte im Speicher mit noch nicht angeforderten Daten füllt, die ohnehin etwas später dann doch angefragt werden.

Und so ging es weiter … bis ich selbst mit der Entwicklung von Grafiktools begann. Da wurden kleine Einzelgrafiken aus Dateien geladen und auf den Bildschirm gemalt. Auf dem 486 lief das gerade noch, auf meinem älteren 386 war es unannehmbar.
Und wo lag der Fehler?
Die Grafiken wurden oft mehrfach pro Bildschirm genutzt. Ich lud sie jedes mal neu von der Platte bzw. Diskette.
Also entwickelte ich eben einen Cache, der die häufigsten Bilder im Speicher behielt. Schon lief das Program auf den 4 mal langsameren 386 problemlos.

Fazit

Caches gehören zu den wichtigsten Instrumenten der Hardware UND der Programmierung, und sie sind im Idealfall perfekt an das bevorzugte Anwendungsszenario angepasst. Dadurch erlauben sie Performance-Boosts jenseits der Skala, wenn man sie richtig einsetzt.

Heute leben wir mit Webanwendungen, die sich durch große Datensammlungen hervortun. Es ist eine Milchmädchen-Rechnung, dass “eine Datenbank” automatisch die beste Performance liefert. Eine Datenbank kann bestenfalls Teilergebnisse verbessern.

Die wirklichen Sprünge erreicht man, wenn die Programmierer die ideale Balance beim Verarbeiten der Informationen finden. Und Caches sind hier gerade bei Daten, die sich selten ändern und häufig gelesen werden, ein hervorragendes Mittel der Optimierung.