Wat kost een beetje regen?

De Mac en de build die ik testte

Deze run gebruikte een MacBook Pro met een Apple M4 Max, 64 GB geheugen en macOS 27.0. Het ingebouwde scherm was 3456 × 2234 pixels op 2× schaal, met een gerapporteerde verversingsfrequentie van 120 Hz. De Mac was aangesloten op netstroom. Automatische helderheid stond aan, en er werd normaal bureaubladwerk gedaan met negen zichtbare vensters bij het begin. Het was geen geïsoleerde, inactieve laboratoriumomgeving.

De app was een lokale Release-build met het label 1.3 (build 3), gebaseerd op commit 0ed73f4 met extra lokale wijzigingen voor audio en invoertracering die bij de test zijn vastgelegd. Een Release-build gebruikt compileroptimalisaties voor productie. Dat betekent niet dat dit exacte uitvoerbare bestand de versie is die nu in de App Store staat. Ik bewaarde een vaste kopie voordat ik gegevens verzamelde, zodat latere codewijzigingen de geteste app niet konden vervangen.

Hoe een benchmarkrun werkt

Ik meet de native app terwijl die regen op het bureaublad tekent. Een browseranimatie, schermafbeelding of test die buiten beeld tekent, laat niet het volledige verbruik zien van een actieve weerlaag tussen open vensters. Tijdelijke instellingen maken elke fase herhaalbaar zonder de voorkeuren van de gebruiker te overschrijven.

1. Begin met de app afgesloten. Meet één minuut als referentie voor het systeem en start daarna de app met de regen uit. Laat de app 30 seconden tot rust komen en meet drie minuten.
2. Laat regen met standaardinstellingen draaien. Gebruik intensiteit 0,35, kwaliteit Automatisch op 30 fps, vaste wind en diepte, met geluid en deeltjes op de voorgrond uit. Laat het twee minuten opwarmen en meet daarna tien minuten.
3. Laat zware regen draaien. Gebruik maximale intensiteit, kwaliteit Vloeiend op 60 fps, deeltjes op de voorgrond en geluid. Laat het opnieuw twee minuten opwarmen en meet tien minuten.
4. Herhaal drie keer. Herhaalde rondes laten variatie zien die één gunstig getal zou verbergen. Eindig met nog een referentiemeting terwijl de app is afgesloten.
5. Laat regen met standaardinstellingen vier uur draaien. Volg na opnieuw opwarmen het geheugen- en CPU-gebruik gedurende de langere sessie, inclusief de trend tegen het einde.

De volledige reeks duurt ongeveer vijf en een half uur. De testsoftware houdt het beeldscherm wakker en de tijdelijke instellingen staan regen boven schermvullende apps toe. Dat zijn meetomstandigheden, geen bewijs over het normale sluimergedrag van de app. Aparte GPU-traces, netwerkobservaties en een momentopname van de geheugenindeling worden buiten de CPU- en geheugenmetingen uitgevoerd. Ik controleer de logboeken op pauzes, onverwacht afsluiten en overlap met de profiler voordat ik een resultaat accepteer.

De nieuwste resultaten

CPU-percentages gebruiken één kern als 100%, niet de hele processor. Geheugen betekent hier de fysieke geheugenvoetafdruk, inclusief toegerekend grafisch geheugen. Het is niet het kleinere getal voor resident geheugen dat sommige tools tonen. De resultaten met regen uit komen van een nieuwe start met effecten uit, niet van geheugen dat achterblijft na het uitzetten van een actief effect.

De eerste standaardronde is uit voorzorg uitgesloten: een pauzeregel voor een app stopte de regen tegen het einde van de opwarmfase, en de schermafbeeldingstool was ook tijdens het begin van de meetperiode actief. Alle fasen zijn voltooid, maar er bleven slechts twee zuivere, korte standaardmetingen over. Ook het CPU-gebruik bij zware regen verschilde aanzienlijk tussen de rondes. Door wisselende bureaubladactiviteit is die variatie moeilijk alleen aan Weatherling toe te schrijven.

Waarom ik het vier uur laat draaien

Een test van tien minuten kan geheugentoewijzingen missen die zich later opstapelen. Tijdens de duurtest steeg het fysieke geheugengebruik van 379,9 naar 467,1 MiB, met een gemeten piek van 469,7 MiB. De uurgemiddelden waren 421,0, 435,0, 442,8 en 467,0 MiB. Het laatste uur was vrijwel vlak: de berekende trendlijn steeg ongeveer 0,1 MiB per uur.

Die late afvlakking is nuttige informatie, maar bewijst niet dat er geen geheugenlekken zijn. De eerdere groei verdient nog onderzoek. Het gemiddelde CPU-gebruik over vier uur was 5,64% van één kern. Het 95e percentiel was 12,15%, wat betekent dat 95% van de gemeten intervallen op of onder dat niveau lag. Tijdens de duurtest is geen levenscycluspauze vastgelegd. Herhaaldelijk aan- en uitzetten, beeldschermen opnieuw aansluiten en slaap- en waakcycli moeten afzonderlijk worden getest.

GPU-werk en vloeiendheid

Afzonderlijke Metal System Trace-opnamen lieten ongeveer 30 presentatiecallbacks per seconde zien bij standaardkwaliteit en 60 bij zware kwaliteit. De gemiddelde actieve GPU-tijd en het 95e percentiel per commandobuffer waren 0,307 / 0,758 milliseconde voor standaard en 0,375 / 0,596 milliseconde voor zwaar. Ter vergelijking: een frame bij 30 fps heeft 33,3 ms beschikbaar; bij 60 fps is dat 16,7 ms.

Elke trace duurde ongeveer 31 seconden. Bij standaardkwaliteit was er één pauze tussen callbacks van meer dan 50 ms, en bij zware kwaliteit waren er 15 van meer dan 25 ms. Deze callbacks helpen de regelmaat te beschrijven, maar zijn geen rechtstreekse meting van beeldschermvertraging of een exact aantal overgeslagen frames. GPU-uitvoeringstijd is ook geen percentage GPU-bezetting. Ik houd de extra belasting van de profiler apart van de langere CPU- en geheugenmetingen.

Hoe zit het met de batterijduur?

Deze meting vertelt niet hoeveel minuten batterijduur Weatherling kost. Tijdens de korte rondes verzamelde ik schattingen van het systeemvermogen en observeerde ik WindowServer, het macOS-proces dat het bureaublad samenstelt. Die waarden omvatten andere apps en wisselend bureaubladwerk. De ene meting van een druk systeem van de andere aftrekken levert geen betrouwbaar wattage voor alleen deze app op.

De vermogensmeting begon halverwege de eerste fase met effecten uit en eindigde vroeg in de duurtest. Voor de eerste referentiemeting met de app afgesloten en het grootste deel van de vier uur zijn er daarom geen vermogensgegevens. Een bruikbare uitspraak over batterijduur vereist gecontroleerde tests op de batterij, met vaste helderheid en belasting, en vergelijkingen met de app actief en afgesloten. Die test heb ik hier nog niet voltooid.

Hoe ik de metingen eerlijk houd

De CPU-meettool leest de procestellers van macOS. De tijdsomrekening wordt gecontroleerd aan de hand van een CPU-klok voor het proces. Ongeveer elke twee seconden meet hij fysiek geheugen en schijf-I/O. Ik bewaar de hash van het uitvoerbare bestand, appversie, broncodestatus, instellingen, tijdstempels en levenscycluslogboeken. Zo is elk resultaat naar de bijbehorende meting te herleiden. Profiling was afgerond voordat de meetperiodes begonnen en de opgeslagen instellingen waren na afloop ongewijzigd.

Korte netwerkmomentopnamen zijn alleen waarnemingen tijdens die periodes. Een lege momentopname bewijst niet dat er nooit netwerkverkeer is. Ook betekenen nul fysieke schrijfacties naar de schijf niet dat er geen logische bestandsactiviteit is. Ik bewaar ruwe traces lokaal, omdat ze informatie over andere processen op de test-Mac kunnen bevatten. Deze pagina publiceert de samengevoegde bevindingen en omstandigheden.

Er zijn nog metingen nodig op minder krachtige Macs, met externe beeldschermen, op batterijvoeding, in de energiebesparingsmodus en bij systematische slaap- en beeldschermovergangen. Deze meting isoleert ook niet het verbruik van afzonderlijke Lings™. Toekomstige metingen volgen waar mogelijk dezelfde reeks. Wijzigingen in hardware, instellingen en build worden daarbij benoemd, niet vermengd tot één hoofdgetal.

Als de prestaties anders aanvoelen op je Mac, stuur een rapport met je Mac-model, appversie, schermopstelling en regeninstellingen. Die details helpen om een algemene zorg om te zetten in een test die ik kan herhalen.