Zig-libc kann SQLite-JSON um Faktor 12.000 bremsen
In einem dokumentierten Fall dauerte es plötzlich Minuten statt Millisekunden, eine 1,2 MB große JSON-Datei zu verarbeiten. Ursache war eine Neuschreibung von Funktionen der C-Standardbibliothek in Zig. Bei bestimmten SQLite-Operationen führte sie zu einer etwa 12.000-fachen Verlangsamung. Der Fall betrifft keinen allgemeinen Leistungseinbruch der Datenbank. Er betrifft einen Verarbeitungspfad, dessen Kosten mit größeren Eingaben massiv wachsen.
Für Entwickler liegt die unangenehme Nachricht in der Build-Kette: Entdeckt wurde das Problem in einem Rust-Projekt, das SQLite über cargo-zigbuild für Linux kompilierte. Dadurch kam Zigs libc-Implementierung ins Spiel. Wer bei einer langsamen Anwendung ausschließlich den Rust-Code oder die Datenbankabfragen untersucht, kann die Ursache deshalb leicht an der falschen Stelle suchen.
Die Build-Kette verändert das Laufzeitverhalten
cargo-zigbuild war in diesem Projekt das Werkzeug für die Cross-Kompilierung. Dabei wird Software für ein anderes Zielsystem gebaut. Auch die eingebundene C-Bibliothek SQLite musste diesen Weg nehmen. In der betroffenen Konfiguration verwendete sie anschließend Funktionen aus Zigs libc-Implementierung.
Die libc stellt grundlegende Funktionen bereit, darunter Routinen zur Verarbeitung von Zeichenketten. Solche Aufrufe liegen tief unter der eigentlichen Anwendungslogik. Trotzdem bestimmen sie mit, wie schnell eine Datenbank ihre Arbeit erledigt. Eine andere Implementierung kann also das Laufzeitverhalten verändern, obwohl sich an der darüberliegenden Anwendung nichts ändern muss.
Genau darin steckt die praktische Falle. Ein erfolgreicher Build bestätigt zunächst, dass sich die Anwendung erstellen lässt. Er bestätigt keine vergleichbare Verarbeitungsgeschwindigkeit. Im beschriebenen Fall wurde diese Lücke beim Tokenisieren großer JSON-Daten sichtbar, also beim Zerlegen des Textes in seine Bestandteile.
Warum ein kleiner String-Aufruf so teuer wird
Die Ursache ist ein klassisches Muster namens „Shlemiel the Painter“. Betroffene Funktionen wie strspn messen in Zigs libzigc-Implementierung zunächst die gesamte Länge einer Zeichenkette. Wird eine solche Funktion beim schrittweisen Verarbeiten eines langen Textes immer wieder aufgerufen, fällt diese Längenbestimmung ebenfalls immer wieder an.
Ein einzelner Durchlauf über einen Text muss noch kein Problem sein. Teuer wird es, wenn jeder kleine Verarbeitungsschritt erneut einen großen Rest des Textes durchläuft. Dann wächst die Arbeit quadratisch mit der Datenmenge. Vereinfacht heißt das: Eine doppelt so große Eingabe kann ungefähr die vierfache Arbeit verursachen. Das ist eine Eigenschaft des Algorithmus, keine Messung für jede denkbare SQLite-Abfrage.
Bei kleinen Testdaten bleibt ein solches Muster leicht unauffällig. Größere Eingaben legen es offen. Die dokumentierte JSON-Datei mit 1,2 MB führte bereits zum Sprung von Millisekunden auf Minuten. Mehr Rechenleistung behebt die Ursache nicht: Der Code erledigt unnötige Arbeit, deren Umfang mit der Eingabe überproportional steigt.
Die Zahl gilt nicht für ganz SQLite
Die etwa 12.000-fache Verlangsamung ist drastisch. Sie beschreibt aber bestimmte Operationen in der betroffenen Konfiguration. Daraus lässt sich weder ableiten, dass jede SQLite-Abfrage so stark ausgebremst wird, noch dass jedes mit Zig gebaute Programm betroffen ist. Auch Rust ist hier nicht der Ort des beschriebenen Algorithmusfehlers.
Dennis Forbes veröffentlichte die detaillierte Beschreibung am 26. Oktober 2026. Entscheidend für die technische Einordnung ist die Kombination aus dem Build-Weg, der eingesetzten libc-Implementierung und einem Zugriffsmuster, das deren Schwäche auslöst. Die Aussage „SQLite ist langsam“ wäre dafür viel zu grob.
Für Nutzer einer betroffenen Anwendung zählt dagegen das sichtbare Ergebnis: Ein Datenverarbeitungsschritt braucht plötzlich erheblich länger. Ob die Wartezeit in der Datenbank, einer Bibliotheksfunktion oder dem eigenen Programmcode entsteht, macht die Anwendung im Alltag nicht brauchbarer.
Was Entwickler jetzt prüfen sollten
Wer cargo-zigbuild zusammen mit SQLite einsetzt und ungewöhnlich lange JSON-Verarbeitungszeiten beobachtet, sollte deshalb die tatsächlich verwendete libc in die Fehlersuche aufnehmen. Der Name des Datenbanksystems allein reicht zur Einordnung nicht. Auch die Werkzeuge und Bibliotheken, mit denen es gebaut wurde, gehören dazu.
Sinnvoll sind Vergleichsmessungen mit unterschiedlich großen Eingaben auf dem vorgesehenen Zielsystem. Wächst die Laufzeit viel stärker als die Datenmenge, ist das ein konkreter Anlass, den Verarbeitungspfad genauer zu untersuchen. Ein kurzer Funktionstest mit einer kleinen Datei deckt dieses Verhalten nicht zuverlässig ab.
Der Fall liefert damit einen klaren Maßstab für einen Bibliotheksersatz: Korrekte Ergebnisse reichen nicht aus. Auch das Laufzeitverhalten muss zu realistischen Datenmengen passen. Für Projekte mit dieser Build-Kette gehört ein solcher Leistungstest zur Prüfung des fertigen Programms.
