36Performance

zplCore.com generates 200,000+ real shipping labels per second (100 × 150 mm, 33 elements, QR + Code 128 + GS1-128) from dictionary or JSON records into a ZPL file – under JIT and NativeAOT, measured on an Apple M3 Max (14 cores), .NET 10, median of 5 runs, samples/ShippingBench.

Real shipping label (samples/ShippingBench)

Measured on 21 Oct 2026: Apple M3 Max (10 performance + 4 efficiency cores), macOS 26.6, .NET 10, Release, workstation GC; one warm-up run, then the median of 5 runs. End to end: records → ZPL → file on disk (StreamWriter, 64 KB buffer). All data sources write a byte-identical 131 MB file (SHA-256 checked before measuring), under JIT and NativeAOT alike.

The label: samples/templates/printjob.json, a 100 × 150 mm (4 × 6 in) shipping label with 33 elements – sender block, inverted service box, recipient (country via expression), routing code, weight, parcels, ship date (Format(ToDate([ShipDate]), "dd.MM.yyyy")), QR code (tracking URL), Code 128 (tracking number), GS1-128 SSCC, page counter, frames and rules – plus a start and an end label. The records vary like real data (umlauts, double names, 9 places in AT/DE/CH/IT, 6 services, 2.5–29 kg, valid SSCCs). Downloads: label as PDF / ZPL, print job (start + 3 shipments + end) as PDF / ZPL (300 dpi), image PNG 300 dpi.

For mass data, pass dictionaries or JSON records: they stay above 200,000 labels/s under JIT and NativeAOT (slowest single run 208,068/s). POCO binding reaches about 125,000/s under JIT and 84,000/s under NativeAOT.

5 million records and Docker (NativeAOT): records as JSON Lines (1.56 GB, one record per line), read line by line, bound as JsonElement, streamed into a 6.53 GB ZPL file. Same Apple M3 Max; Docker Desktop runs the container in a VM, so file I/O to the volume is slower than native.

Memory stays constant for any number of records (a streamed source is neither counted nor buffered). Image build/Dockerfile.shippingbench: 127 MB, runtime-deps:10.0-noble-chiseled-extra, native binary only, non-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 million JSON Lines records
dotnet run -c Release --project samples/ShippingBench -- sample out/sample        # label as PNG/PDF/ZPL

Small 7-element label (samples/PerfTest)

samples/PerfTest generates 100,000 labels in a single print job (start label + 100,000 labels + end label, cut only after the last label) – from objects, streamed from EF Core/SQLite and from LiteDB. It uses a small 100 × 60 mm label with 7 elements (text, expression, number format, Code 128, counter), not the shipping label above. Measured in a Release build on 14 cores (Apple M3 Max, .NET 10), single run.

Generating ZPL for the printer is practically free and streams with constant memory. The stored format halves the amount of data transferred.

The ZPL tests bind classes (Shipment objects) and therefore generate sequentially; dictionary, JSON and DataRow records are generated on all cores – see parallel job generation.

Render optimization

Black-and-white labels are written as 8-bit grayscale PNG (with anti-aliasing) or true 1-bit PNG (AntiAlias = false) instead of 32-bit RGBA (ZplRenderSettings.CompactPng, PngCompression Fastest/Optimal/SmallestSize). Simple ^GB boxes are drawn directly, and the label image is only copied when ^MC N needs it.

Parallel scaling

SkiaSharp serializes two things globally: Skia's glyph cache (every DrawText) and SkiaSharp's handle table (every newly created SKPaint/SKFont/SKBitmap – and DrawBitmap, which internally creates an SKImage every time). zplCore.com therefore rasterizes each glyph once per font/size into a lock-free cache of SKImage masks and draws text via DrawImage; fonts are passed through explicitly instead of being queried via SKFont.Typeface. Results measured with samples/RenderBench -- 150 scale (Apple M3 Max, 10 performance + 4 efficiency cores):

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

dotnet run -c Release --project samples/RenderBench -- 500   # micro-benchmark per element

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

Web API throughput

ASP.NET Core minimal API from samples/WebApiDemo: 14 cores (Apple M3 Max), server GC, 14 workers, small 100 × 60 mm label at 203 dpi (not the shipping label above); client and server in the same process.

ZPL generation saturates at about 199,000 labels/s (from 4 parallel requests); more clients only add latency. Rendering costs about 40× more and scales with the cores. Queue latency includes the wait time (all jobs submitted at once).

Memory and soak test

All figures are measurements with the benchmarks in the repository, not a guarantee.