← EnergyViewAankoopanalyse: echte export, time-out en CPU-profiel
Aanleiding: de diagnose bevat twee aankoopjobs die na 90 seconden stoppen. De huidige woning rondt af in circa 20 seconden plus 12 seconden maatonderzoek. De aankoopkaart blijft na een fout ten onrechte op Analyse bezig: de rejection-handler ververst die kaart niet.
De export is uitsluitend lokaal gereproduceerd, niet opgenomen in broncode, tests of deployment. Het scenario bevat 35.040 kwartieren, geplande PV/EV en batterijinteresse; de hoofdvergelijking test 18 contract/metertypecombinaties en aanvullende batterijmaten. De eerdere synthetische aankoopbenchmark bevat minder contracten en voorspelt deze duur dus onvoldoende.
Gemeten op dezelfde Node-host, met CPU-sampling
| Proef | Volledige aankoopanalyse | Uitkomst |
|---|
| Referentie v265 | 108,24 s | boven oorspronkelijke 90 s limiet |
| Cache van 8 naar 64 MiB | 91,42 s | verworpen: meer geheugen, onvoldoende winst |
| Lege batterij zonder toegestane laadbron herkennen | 93,71 s | behouden |
| DP-overgangslus in kleine eigen functie | 86,71 s | behouden, zelfde loopvolgorde/tolerantie |
Dit zijn afzonderlijke runs, geen statistische p95 of telefoonmeting. De cache blijft 8 MiB. De laatste run heeft exact dezelfde opgeslagen bedragen, selectie, vergelijkingen en gekozen kwartierschema's als de private referentie (deepEqual, zonder de verstreken tijd). De 100 deterministische solvercases en het volledige jaar worden bovendien tegen de oude solver vergeleken. battery-idle.mjs controleert het nieuwe pad, inclusief negatieve prijzen, reserve, registers/SOC, externe kosten en ongeldige invoer. Arbitrary callbacks blijven op het oorspronkelijke pad.
Top 10 self-time van de oorspronkelijke private replay:
| Functie / bestand | Tijd | Aandeel van circa 108 s |
|---|
| dynamicBattery / battery-dispatch.js | 42,96 s | 39,8% |
| garbage collector | 10,94 s | 10,1% |
| sessionFlow / fair-charging.js | 6,92 s | 6,4% |
| repriceHistorical / historical.js | 5,86 s | 5,4% |
| fairCharging / fair-charging.js | 4,43 s | 4,1% |
| dayAheadDispatch / day-ahead-dispatch.js | 4,02 s | 3,7% |
| priceScenario / report-pricing.js | 3,38 s | 3,1% |
| anonieme kwartierbewerking / dynamic.js:56 | 3,32 s | 3,1% |
| policyKey / battery-policy-cache.js | 2,40 s | 2,2% |
| registerSchedule / meter-profile.js | 1,93 s | 1,8% |
Taakafhandeling
Een aankoopjob krijgt expliciet maximaal 180 seconden uitvoeringstijd; de gewone woninganalyse blijft op 90 seconden. Wachttijd in het bestaande workerbudget valt buiten die uitvoeringstijd. Dit verhoogt de marge voor daadwerkelijk benodigde berekening; het is geen rekensnelheidswinst en garandeert geen afloop op elk toestel.
De voortgang noemt nu het huidige contract (x van 18), metertype en geteste batterijmaat. De rejection-handler ververst onmiddellijk de vergelijkingstegel; een gestopte aankoopanalyse meldt Analyse niet afgerond en verwijst naar opnieuw proberen. De tests oefenen de echte failure-handler en de verschillende deadlines met een deterministische klok.
Reproduceerbare publieke controles: npm test en npm run perf:golden. De eerdere doelen van <2 seconden en maximaal 50 ms main-threadtaken zijn hiermee nog niet aangetoond. Geen contract of batterijmaat is verwijderd. De resterende hoofdknelpunten zijn de uitgebreide dagvooruit-DP/EV-combinaties, garbage collection en herprijzing; geen claim van een wereldwijd optimale regeling.