Ile kosztuje odrobina deszczu?

Testowany Mac i kompilacja

Do tego pomiaru użyłem MacBooka Pro z Apple M4 Max, 64 GB pamięci i macOS 27.0. Wbudowany ekran miał 3456 × 2234 pikseli w skali 2× i zgłaszaną częstotliwość odświeżania 120 Hz. Mac był podłączony do zasilania. Automatyczna jasność pozostała włączona, a zwykła praca na biurku trwała dalej, z dziewięcioma widocznymi oknami na starcie. Nie było to odizolowane, bezczynne biurko laboratoryjne.

Aplikacja była lokalną kompilacją Release oznaczoną jako 1.3 (build 3), opartą na commicie 0ed73f4 z dodatkowymi lokalnymi zmianami w dźwięku i śledzeniu wejścia, zapisanymi razem z testem. Kompilacja Release korzysta z produkcyjnych optymalizacji kompilatora; nie oznacza to, że ten konkretny plik wykonywalny jest wersją obecnie dostępną w App Store. Przed zbieraniem danych zamroziłem jego kopię, aby późniejsze zmiany w kodzie nie podmieniły testowanego pliku.

Jak przebiega test

Mierzę natywną aplikację rysującą deszcz na biurku. Animacja w przeglądarce, zrzut ekranu czy test renderowania poza ekranem nie pokażą mi pełnego kosztu utrzymywania żywej nakładki między otwartymi oknami. Tymczasowe ustawienia sprawiają, że każdą fazę da się powtórzyć bez nadpisywania preferencji użytkownika.

1. Zacznij od zamkniętej aplikacji. Zapisz minutowy pomiar bazowy systemu, a potem uruchom aplikację z wyłączonym deszczem. Daj jej 30 sekund na ustabilizowanie się i zbieraj próbki przez trzy minuty.
2. Uruchom domyślny deszcz. Użyj intensywności 0,35, jakości Automatycznie przy 30 kl./s, stałego wiatru i głębi, z wyłączonym dźwiękiem i cząsteczkami przy kamerze. Rozgrzewka przez dwie minuty, potem pomiar przez dziesięć.
3. Uruchom ulewę. Użyj maksymalnej intensywności, jakości Płynnie przy 60 kl./s, cząsteczek przy kamerze i dźwięku. Znów dwie minuty rozgrzewki i dziesięć minut pomiaru.
4. Powtórz trzy razy. Powtarzane rundy pokazują zmienność, którą ukryłaby jedna korzystna liczba. Na koniec kolejny pomiar bazowy z zamkniętą aplikacją.
5. Zostaw domyślny deszcz na cztery godziny. Po świeżej rozgrzewce śledź pamięć i CPU przez całą dłuższą sesję, łącznie z trendem pod jej koniec.

Cała sekwencja trwa około pięciu i pół godziny. Środowisko testowe nie pozwala ekranowi zasnąć, a tymczasowe ustawienia pozwalają padać deszczowi nad aplikacjami pełnoekranowymi. To warunki pomiaru, a nie dowód na to, jak aplikacja normalnie zachowuje się przy uśpieniu. Osobne ślady GPU, obserwacje sieci i zrzut mapy pamięci są wykonywane poza oknami próbkowania CPU i pamięci. Zanim przyjmę wynik, sprawdzam w logach wstrzymania, nieoczekiwane zamknięcia i nakładanie się profilera.

Najnowsze wyniki

Wartości procentowe CPU przyjmują jeden rdzeń jako 100%, a nie cały procesor. Pamięć to fizyczny ślad pamięci, który obejmuje rozliczenie grafiki; nie jest to mniejsza wartość pamięci rezydentnej, którą czasem pokazują inne narzędzia. Wyniki z wyłączonym deszczem pochodzą ze świeżych uruchomień z wyłączonym efektem, a nie z pamięci zachowanej po wyłączeniu aktywnego efektu.

Pierwszą domyślną rundę ostrożnie wykluczyłem: reguła wykluczonej aplikacji wstrzymała deszcz pod koniec rozgrzewki, a aktywność narzędzia do zrzutów ekranu przekroczyła granicę okna próbkowania. Wszystkie fazy się zakończyły, ale uzyskałem tylko dwie czyste krótkie rundy domyślne. Zużycie CPU przy ulewie też wyraźnie różniło się między rundami. Zmienna aktywność na biurku utrudnia przypisanie tej zmienności wyłącznie Weatherling.

Dlaczego zostawiam go na cztery godziny

Dziesięciominutowy test może przeoczyć alokacje, które narastają później. W teście wytrzymałości pamięć fizyczna wzrosła z 379,9 do 467,1 MiB, a najwyższa zarejestrowana wartość wyniosła 469,7 MiB. Średnie godzinowe wyniosły 421,0, 435,0, 442,8 i 467,0 MiB. Ostatnia godzina była niemal płaska: dopasowany trend wynosił około +0,1 MiB na godzinę.

To późne wypłaszczenie jest cennym dowodem, ale nie przesądza, że nie ma wycieków. Wcześniejszy wzrost nadal wymaga zbadania. Średnie zużycie CPU przez cztery godziny wyniosło 5,64% jednego rdzenia; 95. percentyl wyniósł 12,15%, co oznacza, że 95% badanych odcinków mieściło się na tym poziomie lub poniżej. W trakcie testu wytrzymałości nie zapisano żadnego wstrzymania cyklu życia. Wielokrotne przełączanie, ponowne podłączanie ekranów i cykle uśpienia oraz wybudzania wymagają osobnych testów.

Praca GPU i płynność

Osobne nagrania Metal System Trace zarejestrowały około 30 wywołań prezentacji na sekundę przy jakości domyślnej i 60 przy ulewie. Średni / 95. percentyl aktywnego czasu GPU na bufor poleceń wyniósł 0,307 / 0,758 milisekundy dla ustawień domyślnych i 0,375 / 0,596 milisekundy dla ulewy. Dla porównania: klatka przy 30 kl./s ma budżet 33,3 ms, a przy 60 kl./s 16,7 ms.

Każdy ślad obejmował około 31 sekund. W trybie domyślnym wystąpiła jedna przerwa między wywołaniami dłuższa niż 50 ms, a przy ulewie 15 przerw dłuższych niż 25 ms. Te wywołania pomagają opisać tempo, ale nie są bezpośrednim opóźnieniem wyświetlania ani dokładną liczbą pominiętych klatek. Czas wykonania na GPU to też nie procent wykorzystania GPU. Narzut samego profilera oddzielam od dłuższych pomiarów CPU i pamięci.

A co z baterią?

Ten pomiar nie odpowie, o ile minut Weatherling skraca pracę na jednym ładowaniu. W krótkich rundach zbierałem systemowe szacunki zużycia energii i obserwowałem WindowServer, proces macOS, który składa obraz biurka. Te odczyty obejmują inne aplikacje i zmienną pracę na biurku. Odjęcie jednego odczytu zajętego systemu od drugiego nie dałoby wiarygodnej mocy samej aplikacji.

Rejestrowanie energii zaczęło się w trakcie pierwszej fazy z wyłączoną aplikacją i skończyło na początku testu wytrzymałości. Początkowy pomiar bazowy z zamkniętą aplikacją i większość czterogodzinnej fazy nie mają więc próbek energii. Rzetelne stwierdzenie o czasie pracy na baterii wymaga kontrolowanych testów bez zasilacza, stałej jasności i obciążenia oraz porównań z uruchomioną i zamkniętą aplikacją. Tego testu tu jeszcze nie przeprowadziłem.

Jak dbam o rzetelność pomiarów

Próbnik CPU odczytuje liczniki procesów macOS, a jego przeliczanie czasu jest sprawdzane względem zegara CPU procesu. Próbkuje pamięć fizyczną i operacje dyskowe mniej więcej co dwie sekundy. Zapisuję skrót pliku wykonywalnego, wersję aplikacji, stan kodu źródłowego, ustawienia, znaczniki czasu i logi cyklu życia, aby każdy wynik dało się powiązać z przebiegiem, który go dał. W tym pomiarze profilowanie zakończyło się przed mierzonymi oknami, a zapisane ustawienia nie zmieniły się później.

Krótkie migawki sieci to tylko obserwacje z tych okien; pusta migawka nie dowodzi, że aplikacja nigdy nie korzysta z sieci. Podobnie zero fizycznych zapisów na dysk nie oznaczałoby zerowej logicznej aktywności plików. Surowe ślady przechowuję lokalnie, bo mogą zawierać informacje o innych procesach na testowym Macu. Ta strona publikuje zbiorcze wyniki i warunki.

Wciąż potrzebuję pomiarów na słabszych Macach, z zewnętrznymi ekranami, na baterii, w trybie niskiego zużycia energii oraz systematycznych testów uśpienia i zmian ekranów. Ten pomiar nie wyodrębnia też kosztu poszczególnych Lingów™. Przyszłe pomiary będą w miarę możliwości korzystać z tej samej sekwencji, a zmiany sprzętu, ustawień i kompilacji będą wyraźnie zaznaczane, zamiast ginąć w jednej liczbie w nagłówku.

Jeśli na twoim Macu wydajność wydaje się inna, wyślij zgłoszenie z modelem Maca, wersją aplikacji, konfiguracją ekranów i ustawieniami deszczu. Te szczegóły pomagają zamienić ogólny niepokój w test, który mogę powtórzyć.