Swift stosuje optymalizację kompilatora znaną jako wykorzystanie dodatkowych zamieszkań (lub pakowanie wolnych bitów), aby wyeliminować nadmierne obciążenie pamięci dla przypadku none w Optional. Dla typów odniesienia (klas, zamknięć, AnyObject) podstawowa reprezentacja wskaźnika zawiera adres null (0x0), który nie jest ważnym odniesieniem do obiektu; Swift ponownie wykorzystuje ten wskaźnik null do reprezentacji Optional.none, podczas gdy wszystkie nie-nullowe wskaźniki reprezentują Optional.some. Przy rozszerzaniu tego na ogólne enumeracje z wieloma przypadkami zawierającymi ładunki, kompilator analizuje wzory bitowe wszystkich typów wartości powiązanych, aby zidentyfikować wspólne nieużywane wartości (wolne bity). Jeśli wszystkie typy ładunków dzielą co najmniej wystarczającą liczbę wolnych bitów do zakodowania liczby przypadków, enumeracja przechowuje dyskryminator przypadku w tych bitach; w przeciwnym razie dodaje oddzielny bajt lub słowo znacznikowe.
Podczas projektowania grafu scen w silniku renderującym 3D w czasie rzeczywistym, zespół potrzebował przechowywać opcjonalne odniesienia do rodziców dla 2 milionów węzłów sceny. Każdy węzeł był instancją klasy, a hierarchia wymagała Optional<Node> do reprezentacji węzłów głównych (które nie mają rodzica).
Rozwiązanie A: Równoległa tablica boolean.
Zespół rozważył utrzymywanie oddzielnej ContiguousArray<Bool> obok ContiguousArray<Node>, aby wskazać obecność rodzica.
Zalety: Eksploracja kontrola, niezależny od języka wzór.
Wady: Lokalność pamięci jest niszczona przez dostęp do dwóch odrębnych obszarów pamięci; wzrost overheadu pamięci o 2 MB (1 bajt na bool, wyśrubowane do wyrównania); złożoność synchronizacji przy restrukturyzacji drzewa.
Rozwiązanie B: Wzorzec węzła sentinelu.
Zastosowanie globalnej instancji „null node” do reprezentacji nieobecnych rodziców.
Zalety: Przechowywanie pojedynczego wskaźnika, brak overheadu opcjonalnego.
Wady: Narusza bezpieczeństwo typów; kompilator nie może zapobiec przypadkowym operacjom na sentinelu; wymaga defensywnych sprawdzeń w całej bazie kodu; wprowadza cykle odniesień, jeśli sentinel przechowuje odniesienia do rzeczywistych węzłów.
Rozwiązanie C: Native Swift Optional.
Bezpośrednie zastosowanie Optional<Node> wewnątrz struktury węzła.
Zalety: Pełne bezpieczeństwo w czasie kompilacji, idiomatyczna składnia Swift, zerowy overhead pamięci, ponieważ Optional wykorzystuje reprezentację wskaźnika null dla none.
Wady: Wymaga zrozumienia, że ta optymalizacja dotyczy konkretnie typów odniesienia; typy wartościowe jak Int będą miały padding.
Zespół wybrał Rozwiązanie C. Ponieważ Node był klasą, opakowanie Optional nie dodało żadnych bajtów do rozmiaru instancji. Rezultat był redukcją pamięci o około 16 MB w porównaniu do równoległego podejścia boolean (eliminuje zarówno przechowywanie booleanów, jak i powiązane wyrównanie), jednocześnie uzyskując zapewnienia w czasie kompilacji, które usunęły całą klasę awarii związanych z dereferencjowaniem null w czasie późniejszej refaktoryzacji.
Dlaczego Optional<Int> zazwyczaj zajmuje więcej pamięci niż Int, podczas gdy Optional<AnyObject> zajmuje tę samą przestrzeń co AnyObject?
Int to 64-bitowa liczba całkowita uzupełnienia do dwóch, wykorzystująca każdy możliwy wzór bitowy do reprezentacji swojego zakresu numerycznego (-2^63 do 2^63-1), nie pozostawiając żadnych nieprawidłowych wzorów bitowych (dodatkowych mieszkańców) dostępnych dla dyskryminanta Optional. W konsekwencji kompilator musi dodać oddzielny bajt (lub słowo, ze względu na wyrównanie), aby przechować, czy opcjonalny jest some, czy none. Z drugiej strony, AnyObject (i wszystkie odniesienia do klas) są wskaźnikami, gdzie wzór bitowy zero (null) jest gwarantowane jako nieprawidłowy adres obiektu; Optional przyjmuje tę reprezentację null dla swojego przypadku none, wymagając zero dodatkowego magazynowania.
Ile odrębnych reprezentacji na poziomie maszyny istnieje dla "nieobecności" w Optional<Optional<T>>, gdy T jest klasą, i dlaczego to ma znaczenie dla równości?
Istnieją dwie odrębne reprezentacje: zewnętrzna .none (wskaźnik null na zewnętrznym poziomie) i .some(.none) (ważny wskaźnik zewnętrzny wskazujący na wewnętrzny null). Ponieważ wewnętrzny Optional już wykorzystuje wartość wskaźnika null do reprezentacji swojej własnej pustki, zewnętrzny Optional nie może rozróżnić swojego własnego none od .some zawierającego wewnętrzne none, używając tylko wartości wskaźnika. W związku z tym zewnętrzna warstwa wymaga oddzielnego bitu znacznikowego, a dwa konceptualne stany "nil" nie są równe (Optional(Optional.none) != Optional.none). To rozróżnienie jest kluczowe przy zagnieżdżaniu opcjonalnych wartości zwracanych z generujących interfejsów API lub dekodowaniu JSON, gdzie brakujące klucze produkują zewnętrzne nil i wartości null produkują wewnętrzne nil.
Kiedy definiować enumerację z wieloma przypadkami ładunków, takich jak case integer(Int), case boolean(Bool), co określa, czy kompilator przechowa oddzielny bajt znacznikowy, czy wbudowuje dyskryminator przypadku w ładunek?
Kompilator przeprowadza analizę wolnych bitów dotyczących powiązanych typów wartości. Bool używa tylko najmniej znaczącego bitu, pozostawiając 7 bitów wolnych. Jeśli ładunki wszystkich przypadków dostarczają wystarczającej ilości wolnych bitów, aby unikalnie zidentyfikować każdy przypadek (np. wiele odniesień klasowych dzielących null jako dodatkowego mieszkańca), enumeracja mogłaby pakować indeks przypadku w te nieużywane bity. Jednak Int i Bool mają niezgodne wzory wolnych bitów (Int nie ma), zmuszając kompilator do przypisania oddzielnego bajtu znacznikowego (lub słowa), aby rozróżnić integer od boolean, zwiększając rozmiar enumeracji powyżej maksymalnego rozmiaru ładunku.