36Performance

zplCore.com erzeugt über 200.000 echte Versandetiketten pro Sekunde (100 × 150 mm, 33 Elemente, QR + Code 128 + GS1-128) aus Dictionary- oder JSON-Datensätzen in eine ZPL-Datei – unter JIT und NativeAOT, gemessen auf einem Apple M3 Max (14 Kerne), .NET 10, Median aus 5 Läufen, samples/ShippingBench.

Echtes Versandetikett (samples/ShippingBench)

Gemessen am 21.10.2026: Apple M3 Max (10 Performance- + 4 Effizienzkerne), macOS 26.6, .NET 10, Release, Workstation-GC; ein Aufwärmlauf, dann der Median aus 5 Läufen. Ende zu Ende: Datensätze → ZPL → Datei auf der Platte (StreamWriter, 64-KB-Puffer). Alle Datenquellen schreiben eine byte-identische Datei mit 131 MB (vor der Messung per SHA-256 geprüft), unter JIT und NativeAOT gleichermaßen.

Das Etikett: samples/templates/printjob.json, ein Versandetikett 100 × 150 mm (4 × 6 Zoll) mit 33 Elementen – Absenderblock, invertiertes Servicefeld, Empfänger (Land per Ausdruck), Routing-Code, Gewicht, Packstücke, Versanddatum (Format(ToDate([ShipDate]), "dd.MM.yyyy")), QR-Code (Tracking-URL), Code 128 (Sendungsnummer), GS1-128-SSCC, Seitenzähler, Rahmen und Linien – dazu ein Start- und ein End-Label. Die Datensätze variieren wie echte Daten (Umlaute, Doppelnamen, 9 Orte in AT/DE/CH/IT, 6 Services, 2,5–29 kg, gültige SSCCs). Downloads: Etikett als PDF / ZPL, Druckauftrag (Start + 3 Sendungen + Ende) als PDF / ZPL (300 dpi), Bild PNG 300 dpi.

Für Massendaten Dictionary- oder JSON-Datensätze übergeben: Sie bleiben unter JIT und NativeAOT über 200.000 Etiketten/s (langsamster Einzellauf 208.068/s). POCO-Bindung erreicht unter JIT rund 125.000/s, unter NativeAOT 84.000/s.

5 Millionen Datensätze und Docker (NativeAOT): Datensätze als JSON Lines (1,56 GB, ein Datensatz je Zeile), zeilenweise gelesen, als JsonElement gebunden, in eine 6,53 GB große ZPL-Datei gestreamt. Derselbe Apple M3 Max; Docker Desktop führt den Container in einer VM aus, daher ist Datei-I/O auf das Volume langsamer als nativ.

Der Speicher bleibt bei jeder Anzahl an Datensätzen konstant (eine gestreamte Quelle wird weder gezählt noch gepuffert). Image build/Dockerfile.shippingbench: 127 MB, runtime-deps:10.0-noble-chiseled-extra, nur das native Programm, ohne Root.

dotnet run -c Release --project samples/ShippingBench                       # JIT
dotnet publish samples/ShippingBench -c Release -r osx-arm64 -p:PublishAot=true -o out   # NativeAOT
docker build -f build/Dockerfile.shippingbench -t zplcore-shippingbench .
docker run --rm -v zplcore-bench:/data zplcore-shippingbench 1000 10 1 5000000   # + 5 Millionen JSON-Lines-Datensätze
dotnet run -c Release --project samples/ShippingBench -- sample out/sample        # Etikett als PNG/PDF/ZPL

Kleines Label mit 7 Elementen (samples/PerfTest)

samples/PerfTest erzeugt 100.000 Labels in einem Druckauftrag (Start-Label + 100.000 Labels + End-Label, Schnitt nur nach dem letzten Label) – aus Objekten, gestreamt aus EF Core/SQLite und aus LiteDB. Es verwendet ein kleines Label 100 × 60 mm mit 7 Elementen (Text, Ausdruck, Zahlenformat, Code 128, Zähler), nicht das Versandetikett oben. Gemessen im Release-Build auf 14 Kernen (Apple M3 Max, .NET 10), Einzellauf.

Die ZPL-Erzeugung für den Drucker ist praktisch kostenlos und streamt mit konstantem Speicher. Das gespeicherte Format halbiert die übertragene Datenmenge.

Die ZPL-Tests binden Klassen (Shipment-Objekte) und erzeugen deshalb sequenziell; Dictionary-, JSON- und DataRow-Datensätze entstehen auf allen Kernen – siehe parallele Job-Erzeugung.

Render-Optimierung

Schwarz-weiße Labels werden als 8-Bit-Graustufen-PNG (mit Kantenglättung) bzw. echtes 1-Bit-PNG (AntiAlias = false) statt 32-Bit-RGBA geschrieben (ZplRenderSettings.CompactPng, PngCompression Fastest/Optimal/SmallestSize). Einfache ^GB-Rahmen werden direkt gezeichnet, und das Label-Bild wird nur kopiert, wenn ^MC N es braucht.

Parallele Skalierung

SkiaSharp serialisiert zwei Dinge global: Skias Glyph-Cache (jedes DrawText) und SkiaSharps Handle-Tabelle (jedes neu erzeugte SKPaint/SKFont/SKBitmap – und DrawBitmap, das intern jedes Mal ein SKImage anlegt). zplCore.com rastert deshalb jede Glyphe einmal pro Schrift/Größe in einen sperrfreien Cache aus SKImage-Masken und zeichnet Text per DrawImage; Schriften werden explizit durchgereicht statt über SKFont.Typeface abgefragt. Ergebnis gemessen mit samples/RenderBench -- 150 scale (Apple M3 Max, 10 Performance- + 4 Effizienzkerne):

dotnet run -c Release --project samples/RenderBench -- 150 scale [label|text|barcode|box|empty]

dotnet run -c Release --project samples/RenderBench -- 500   # Mikro-Benchmark pro Element

dotnet run -c Release --project samples/PerfTest -- 100000 perf-out

Durchsatz der Web-API

ASP.NET-Core-Minimal-API aus samples/WebApiDemo: 14 Kerne (Apple M3 Max), Server-GC, 14 Worker, kleines Label 100 × 60 mm bei 203 dpi (nicht das Versandetikett oben); Client und Server im selben Prozess.

Die ZPL-Erzeugung sättigt bei etwa 199.000 Labels/s (ab 4 parallelen Requests); mehr Clients erhöhen nur die Latenz. Rendern kostet etwa 40× mehr und skaliert mit den Kernen. Die Queue-Latenz enthält die Wartezeit (alle Jobs auf einmal eingereicht).

Speicher und Dauertest

Alle Zahlen sind Messungen mit den Benchmarks im Repository, keine Zusicherung.