# Leistungsmessungen

Lokaler Entwicklungsrechner, Microsoft OpenJDK 25.0.4.1, Windows x64. Die Werte sind Vergleichswerte
für die Entwicklung und keine garantierten Mindestanforderungen.

## Hessen-Quelldatei

- Datei: `hessen-260822.osm.pbf`
- Größe: 343.841.973 Byte
- Inhalt: 31.820.725 Nodes, 4.905.422 Ways und 62.311 Relations
- SHA-256: `5e0b30ec8dc6d42519e4cc6faadbc68025d81ecbc02100a34b3d75d8cf6bc0ed`

| Vorgang | Ergebnis | Laufzeit / Speicherhinweis |
|---|---:|---:|
| PBF-Blockscan | 4.601 Blöcke | ca. 0,45 s |
| neue PrimitiveBlock-Dekodierung, 1 CPU-Worker | 4.600 Datenblöcke | ca. 11,79 s |
| neue PrimitiveBlock-Dekodierung, 16 CPU-Worker | 4.600 Datenblöcke | ca. 1,95 s (Faktor 6,0) |
| vollständiges Hessen-MTCI, 64 Shards | 1.937.487.164 Byte | ca. 13,60 s |
| räumliche Auswahl des gezeigten 2-%-Rechtecks | 812.732 Nodes innerhalb | ca. 19,43 s |
| referenziell vollständige Auswahl materialisieren | 88.032.102 Byte | ca. 15,64 s + 1,27 s Prüfung |
| optimierte OSM-PBF schreiben | 21.155.011 Byte | ca. 2,63 s |
| Mapsforge-Karte aus optimierter PBF | 6.142.339 Byte | ca. 9,79 s |
| Mapsforge-POIs aus optimierter PBF | 3.911.680 Byte, 9.558 POIs | ca. 11,60 s |
| Vorschauaufbau | 188.378 Linien, 7.464 POIs, 20.000 Beschriftungen | ca. 22,8 s |
| Rechteckzuschnitt 8,15/50,0–8,35/50,2 | 15.895.854 Byte | ca. 158 s |
| vollständige Mapsforge-Karte des Ausschnitts (RAM) | 6.045.885 Byte | ca. 10,8 s, Writer-Schätzung ca. 523 MiB |
| dieselbe Karte mit Festplattenindex (Vergleich) | 6.045.872 Byte | ca. 188 s, Writer-Schätzung ca. 384 MiB |
| Mapsforge-POIs im nativen Paket | 6.717.440 Byte, 15.409 POIs | ca. 15,7 s |
| ausschließlich Straßen | 1.440.981 Byte | ca. 99 s, Writer-Schätzung ca. 670 MiB |

Der Blockscan und die Vorschau lesen die PBF sequenziell und halten keine vollständige Hessen-Datei im
Arbeitsspeicher. Der Mapsforge-Worker wird mit `-Xmx4g` gestartet. PBF-Ausschnitte bis 256 MiB werden
im deutlich schnelleren RAM-Modus verarbeitet; größere Eingaben verwenden weiterhin den sparsameren
HD-Modus. Ist keine PBF-Ausgabe gewählt, erzeugt die Oberfläche vor `.map/.poi` automatisch einen
temporären Ausschnitt, damit nicht die gesamte Quelldatei in den Mapsforge-Writer gelangt.
Die vom Mapsforge-Writer angebotene Geometrievorbereitung verwendet automatisch bis zu acht Threads;
PBF-Einlesen, Relationstopologie und der finale Dateischreiber bleiben in dieser Pipeline seriell.

Die neue Pipeline dekodiert die unabhängig komprimierten Datenblöcke parallel, begrenzt gleichzeitig
gepufferte Blöcke und gibt Ergebnisse trotzdem in Quellreihenfolge weiter. Die beiden maschinenlesbaren
Rohberichte stehen unter `documentation/benchmarks/parallel-pbf-windows.json` und
`documentation/benchmarks/parallel-pbf-windows-1-thread.json`. Gemessen wurde CPU-ZLIB; ein CUDA-Modul
war nicht aktiv. Die Werte belegen nur Scan und Dekodierung, noch nicht Referenzauflösung, Clipping oder
das Schreiben einer Mapsforge-Datei.

Der neue End-to-End-Pfad ist jetzt in den Worker integriert. Beim ersten Auftrag fallen für die
Hessenquelle zusätzlich rund 13,6 Sekunden Cacheaufbau an; Folgeaufträge verwenden den 1,94-GB-Cache.
Der gemessene 2-%-Ausschnitt enthält nach Bereinigung bereits in der Regionalquelle fehlender Mitglieder
1.242.856 Nodes, 180.427 Ways und 2.920 Relations. Die Integritätsprüfung meldet keine doppelten IDs und
keine fehlenden Referenzen. Die direkt geschriebene PBF wurde vom Mapsforge-Map- und POI-Writer 0.29.0
erfolgreich verarbeitet. Die ältere 158-Sekunden-Osmosis-Messung verwendet ein anderes Rechteck und ist
daher nur eine Größenordnung, kein streng identischer A/B-Vergleich.

## Höhenraster-Export

Der GeoTIFF-Writer teilt das Zielraster in unabhängige Streifen. Die Ausführungsrichtlinie reserviert
Speicher für das Betriebssystem und wählt aus verfügbaren logischen Prozessoren, freiem physischen
Speicher und JVM-Heap bis zu 16 Worker sowie Puffer zwischen 1 und 8 MiB. Ein System mit 4 GiB RAM
bleibt bei einem Worker; leistungsfähigere Rechner nutzen zusätzliche CPU-Kerne und Puffer, ohne die
4-GiB-Heapgrenze des isolierten Workers anzuheben.

Gemessen wurden 24 HGT-Kacheln mit zusammen 622.425.648 Byte. Der rechteckige Ausschnitt
7,54401°/48,01706° bis 11,18736°/51,03777° umfasst 142.647.375 Float32-Zellen und erzeugt ein
570.590.372 Byte großes GeoTIFF. Auf dem lokalen Windows-x64-Entwicklungsrechner mit 48 logischen
Prozessoren wählte die Richtlinie 16 Worker und 8-MiB-Puffer. Der vollständige Worker-Lauf benötigte
1,846 Sekunden; zwei Läufe erzeugten denselben SHA-256-Hash
`c7135c8c0fcfa6a68a4f6775bb9de15a0939b219980e7316549b5b984527359c`.

Die alte Implementierung hatte im identischen Größenbereich nach 15:43 Minuten erst 56 Prozent
erreicht. Dieser Vorher-Wert stammt aus der sichtbaren Fortschrittsanzeige des abgebrochenen Laufs und
ist daher kein Laborbenchmark. Der neue Rohbericht steht unter
`documentation/benchmarks/elevation-geotiff-windows-1.5.1.json`.

## Noch zu messen

- vollständiger End-to-End-Auftrag direkt aus der 343-MB-Quelle
- Deutschland-PBF als Lasttest
- Spitzenwerte für CPU, Arbeitsspeicher und temporären Speicher mit einem reproduzierbaren Messskript
- Startzeit und Paketgröße des portablen ZIP auf einem sauberen Windows-11-System
