Wie lange dauert ein Scan wirklich?

Woraus die Zahl entsteht

Der Rechner ist ein Kostenmodell über gemessene Läufe, keine Marketingzahl mit Schieberegler. Jeder Faktor ist entweder eine Messung samt genannter Eingabeform oder eine deklarierte Annahme, und die Seite sagt bei jedem, was von beidem. Die interaktive Fassung braucht JavaScript; das Modell selbst steht ohnehin hier.

• Projektgröße: Der Pfad aus Code, Kontext, AST, TLS, Config und Datenbank wächst mit Dateien hoch etwa 1,37. Gemessen an zwei Größen: 900 Dateien über 12.101.499 Bytes und alle 18 Sprachen in 11,052 s, sowie 25.684 Dateien mit rund 7 Millionen Zeilen in 1.080,5 s. Zwei Punkte legen den Exponenten exakt fest und sagen nichts über den Verlauf dazwischen.
• Historientiefe: rund 18,9 ms je Commit, linear. Einmal gemessen, bei 674.780 Commits in einem 5,7-GB-Pack mit 12.759 s. Bei den meisten Repositories ist das der mit Abstand größte Posten der Schätzung.
• CPU-Kerne: Amdahl-Skalierung mit 13,4 % seriellem Anteil, gelegt durch ein einziges gemessenes Verhältnis. Zwei auf sechzehn Worker ergaben 3,02-fache Wall-Clock-Beschleunigung, während die CPU-Effizienz auf 38 % fiel. Daraus folgt eine Decke: unbegrenzt viele Kerne bringen höchstens das 1,41-fache gegenüber der Sechzehn-Kern-Referenzmaschine.
• Arbeitsspeicher: eine Schwelle, kein Faktor. Der Bedarf liegt bei rund 56 kB je Datei plus 27 kB je Commit, abgeleitet aus 110 MB Spitzenbedarf auf dem kleinen und 19,5 GB auf dem großen Korpus. Oberhalb des Bedarfs ändert mehr RAM nichts. Darunter degradiert der Scan, und unterhalb der Hälfte verweigert der Rechner eine Zahl, weil der Referenzlauf bei diesem Verhältnis nicht bloß langsamer wurde, sondern mit einem Allokationsfehler abbrach.
• Datenträger: wirkt fast ausschließlich auf die Historien-Phase. Der Code-Pfad kann nicht datenträgergebunden sein, denn er verarbeitet Quelltext mit rund 1,1 MB/s, was selbst eine Festplatte um zwei Größenordnungen übertrifft. Ein mehrere Gigabyte großes Pack mit einem Direktzugriff je Commit zu lesen ist ein anderes Regime. Gemessen wurde nur die Referenz-NVMe; die übrigen Geräteklassen sind deklarierte Richtwerte.
• Folgescan: kein fester Prozentsatz. Ein Lauf ohne jede Änderung kostet immer noch einen Boden von rund 17 % des Erstscans, den Rest entscheidet der Anteil geänderter Dateien. An beiden Enden gemessen: 40 parse-teure Module mit einer Änderung gingen von 1,626 s auf 0,553 s, der unveränderte Referenzkorpus von rund 1.080 s auf rund 180 s.
• GPU: kein Faktor und bewusst kein Regler.

Warum gibt es keinen GPU-Regler?

Hier steht kein GPU-Regler, weil es keine GPU-Wirkung zu regeln gibt. Die beiden Phasen, die einen Scan dominieren, sind ein Git-Tree-Diff und eine Reihe von Sprachparsern. Beides ist verzweigungslastige Arbeit mit unvorhersehbaren Speicherzugriffen, also genau das, worin eine GPU am schlechtesten ist. Korthex schickt tatsächlich eine Arbeitslast auf die GPU, einen Delta-Hash, der bitidentisch zum CPU-Pfad ist und bei jedem Fehler auf ihn zurückfällt, und die liegt auf keinem dieser beiden kritischen Pfade. Ein Regler hier würde einen Hebel bewerben, den es nicht gibt.

Referenzmaschine und Referenzkorpus

Jede Zeitmessung im Modell stammt von einem Host und zwei Korpora. Sie zu benennen ist der Punkt: eine Dauer ohne ihre Eingabeform ist eine Illustration, die wie eine Zusage aussieht.

• Host: 8 physische und 16 logische Kerne, 30,9 GB RAM, eine Samsung 980 PRO NVMe, Windows 11.
• Großer Korpus: LibreOffice core, 25.684 Quelldateien, rund 7 Millionen Zeilen, 674.780 Commits, ein 5,7-GB-Pack. Kalt und vollständig dauerte er 3 h 50 min, aufgeteilt in Git-Historie 12.759 s, Kontext 1.009 s, AST 67 s, TLS 1,2 s, Config 1,0 s und Datenbank 2,3 s.
• Kleiner Korpus: die eingecheckte Performance-Baseline aus 900 Dateien, 12.101.499 Bytes über alle 18 Sprachen. Code-Engine-Wall-Clock 11,052 s, Spitzenbedarf 110 MB.

Wo dieses Modell dünn ist

Offen gesagt, weil ein Rechner, der seine Schwachstellen versteckt, eine Behauptung mit Schieberegler ist.

• Zwei gemessene Projektgrößen legen den Exponenten exakt fest und sagen nichts über den Verlauf dazwischen. Alles außerhalb von 900 bis 25.684 Dateien ist Hochrechnung.
• Die Kosten je Commit stammen aus einem einzigen Repository mit einem einzigen Pack. Eine Historie mit breiten Trees oder mit sehr vielen winzigen Commits passt nicht dazu.
• Gemessen wurde nur die Referenz-NVMe. Die Werte für SATA, Festplatte und Netzlaufwerk sind deklarierte Geräteklassen-Richtwerte, und die Festplatten-Schätzung für die Historie ist eine Untergrenze, weil sie nur einen Pack-Zugriff je Commit unterstellt.
• Die Kern-Kurve ist durch ein einziges gemessenes Verhältnis gelegt. Sie trifft dieses Verhältnis exakt und ist überall sonst unbelegt.
• Beim Arbeitsspeicher sind Bedarf und Schwelle gemessen. Die Steigung der Verlangsamung unterhalb der Schwelle ist es nicht.
• Die Spanne selbst ist eine deklarierte Annahme. Das Performance-Gate des Projekts wertet einen Einbruch auf den halben Durchsatz bei gleichem Korpus und gleicher Maschine noch als innerhalb der Toleranz, eine engere Spanne würde also mehr Stabilität behaupten, als das Gate unterstellt.

Häufig gestellte Fragen

Wie lange dauert ein Korthex-Scan?

Das hängt an drei Dingen, und der Rechner auf dieser Seite zeigt alle drei: wie viel Quelltext es gibt, wie tief die Git-Historie reicht und was für eine Maschine läuft. Für eine Codebasis von 500.000 Zeilen mit kurzer Historie auf einer aktuellen Sechzehn-Kern-Workstation setzt das Modell den Erstscan bei etwa anderthalb bis drei Minuten an. Dieselbe Codebasis mit 50.000 Commits Historie liegt bei einer Viertelstunde, weil die Historie meist der dominierende Posten ist.

Ist ein Scan von 50.000 bis 500.000 Zeilen unter zwei Minuten fertig?

Für die reine Quellcode-Analyse bequem: Das Modell unter korthex.de/scan-duration setzt 500.000 Zeilen bei rund einer halben Minute auf der Referenzmaschine an, 50.000 Zeilen bei ein bis zwei Sekunden. Ob der gesamte Lauf unter zwei Minuten bleibt, entscheidet die Git-Historie, die in dieser Zahl nicht enthalten und häufig größer als sie ist. Genau deshalb ist die pauschale Zusage durch den Rechner unter korthex.de/scan-duration ersetzt worden.

Wird der Scan mit mehr Arbeitsspeicher schneller?

Nur bis zu dem Punkt, an dem genug da ist. RAM ist eine Schwelle, keine Drossel: oberhalb dessen, was der Arbeitssatz braucht, ändert mehr davon nichts Messbares. Darunter degradiert der Scan, und deutlich darunter kann der Lauf ganz scheitern statt nur länger zu dauern, was auf dem Referenzkorpus bei 19,5 GB Spitzenbedarf geschah.

Beschleunigt eine GPU einen Korthex-Scan?

Nein, und der Rechner bietet bewusst keinen GPU-Regler. Git-Tree-Diffing und Sprachparsing sind verzweigungslastige Arbeit mit unvorhersehbaren Speicherzugriffen, also die Arbeitsklasse, mit der eine GPU am schlechtesten umgeht. Korthex lässt eine Hash-Arbeitslast auf der GPU laufen, bitidentisch zum CPU-Pfad und auf ihn zurückfallend, und die liegt auf keiner der beiden dominierenden Phasen.

Wie viel schneller ist ein Folgescan?

Er ist kein fester Prozentsatz, weshalb der Rechner nach dem Anteil des Geänderten fragt. Ein Lauf ohne jede Änderung zahlt weiterhin einen Boden von rund 17 % des Erstscans. Von dort steigen die Kosten mit dem Anteil geänderter Dateien und mit der Zahl neuer Commits, bis hin zu den Kosten eines Kaltscans, wenn sich alles geändert hat.