Footprint-attributen kosten twintig keer zoveel als de andere standattributen bij het wegschrijven

[jipclaassens]

Waarneming

Bij het wegschrijven van de stand aan het eind van een zichtjaar zijn de zeven footprint-attributen samen goed voor bijna alle tijd, en tijdens die fase piekt het geheugengebruik. Dit viel al eerder op bij losse runs en is nu gemeten op een volledige run van 2030, casus WLO_hoog_NbSGenuanceerd.

Meting

Tijd tussen twee opeenvolgende schrijfregels in het tracelog, dus de kosten om het volgende bestand te produceren en weg te schrijven:

bestand	seconden
OP_rel	59
Wonen, vier subsectoren	1 tot 2 elk
Werken, zes subsectoren	2 elk
Waterberging/Totaal	2
PandFootprint, zes jobtypes	28, 29, 35, 39, 44, 47
Wonen/Footprint	44

Samengevat: de zeven footprint-attributen kosten samen 268 seconden, de elf subsectorstanden samen 21 seconden. Dat is ruwweg een factor twintig per attribuut.

Het is dus niet alleen PandFootprint aan de werken-kant. Wonen/Footprint is met 44 seconden even duur. Het gaat om de footprint-familie als geheel.

Geheugen in dezelfde fase

Gemeten op het moment dat de PandFootprint-bestanden werden geschreven:

werkgeheugen	96,0 GB
private bytes	183,9 GB
commit charge systeem	210,9 GB van 616,2 GB
vrij fysiek	11,1 GiB, dalend

Ter vergelijking: tijdens de allocatie zelf bleef het werkgeheugen ruim onder de 90 GB en bleef er meer dan 17 GiB vrij.

Waar het zit

De footprints worden in elke iteratie van elke sectorallocregio opnieuw bepaald, in StateNaAllocatie0:

• Templates/Allocatie/Iter_T.dms:96 voor Wonen/Footprint
• Templates/Allocatie/Iter_T.dms:106 voor PandFootprint per jobtype
• dezelfde constructie in Templates/Allocatie/Iter_Landbouw_T.dms:150 en :159

De expressies staan in Templates/Allocatie_T.dms:78 tot :88.

Vermoeden

Wat de zeven footprints onderscheidt van de subsectorstanden is dat hun bijwerk-expressie een indexering bevat, en de andere niet.

Update_PandFootprint_Expr haalt per iteratie de dichtheid op via een relatie tussen twee domeinen:

ThisVariantData/Density/Per_CompactedAllocDomain/@Y@/src/Werken/PandFootprint_perJob/Subsectoren/@SS@[CompactedAdminDomain/CompactedAllocDomain_rel]

Update_WoonFootprint_Expr doet iets vergelijkbaars, geindexeerd op het allocatieresultaat van die iteratie:

ThisVariantClassifications/Vastgoed/OP_buurt/Terreinoppervlakte/Uitgeefbaar/GebouwVoetafdruk[Context/ThisIter/Allocatie/per_OP]

Verdring_Expr en Update_Expr_DiscrAlloc, die de subsectorstanden bijwerken, zijn daarentegen puur elementsgewijs op arrays die er al zijn.

Een gather per iteratie, per jobtype, over het volledige CompactedAdminDomain, waarvan de bron een variantdata-array is die daarvoor resident moet zijn, verklaart zowel de tijd als het geheugen. De keten wordt bovendien pas bij het schrijven van de stand opgevraagd, dus alle iteraties van beide sequenties moeten dan tegelijk beschikbaar zijn.

Dit is een vermoeden op grond van de expressies en de meting, niet een vastgestelde oorzaak.

Wat er nog gemeten moet worden

1. Schaalt de kosten mee met het aantal iteraties? Te testen door Default_NrOfIters te verlagen en dezelfde schrijffase te timen.
2. Is de gather de dominante term? Te testen door in een verse sessie alleen een van de zeven footprint-items op te vragen en het geheugen te volgen.
3. Kan de bron van de gather buiten de iteratielus getild worden, zodat hij eenmaal per zichtjaar wordt bepaald in plaats van per iteratie? Dat is de meest voor de hand liggende ingreep als 1 en 2 het vermoeden bevestigen.

Context

Gemeten op de run van 2026-08-22, GeoDMS 20.17 branch lookahead-scheduling, configuratie op branch NL2120. Zie ook #639 voor de bredere controle waar deze meting uit voortkomt.