Mechanizm __slots__ został wprowadzony w Python 2.2, aby rozwiązać duży problem związany z zużyciem pamięci związanym z domyślnym modelem obiektów, który przydziela dla każdej instancji tabelę haszową __dict__ do dynamicznego przechowywania atrybutów. Problem występuje w aplikacjach o dużej skali, gdzie miliony obiektów konsumują setki megabajtów RAM tylko na zarządzanie słownikiem, co prowadzi do presji pamięci i spadków wydajności związanych z brakami w pamięci podręcznej. Rozwiązaniem jest zadeklarowanie __slots__ jako zmiennej klasowej zawierającej iterowalną listę ciągów, co poleca interpreterowi zarezerwować stałe offsety tablicy C dla atrybutów zamiast wyszukiwania haszy, tym samym eliminując __dict__ oraz sloty __weakref__, chyba że zostały one jawnie zażądane.
Ta optymalizacja zmniejsza zużycie pamięci dla każdej instancji o około 40-50% i przyspiesza dostęp do atrybutów, unikając kosztów haszowania. Zapobiega również tworzeniu __weakref__, chyba że jawnie włączone, co dalej zmniejsza rozmiar obiektów. Wprowadza jednak sztywność: instancje nie mogą zdobywać nowych atrybutów dynamicznie, a hierarchie klas muszą utrzymywać spójność slotów, aby uniknąć cichego powrotu do przechowywania w słowniku.
Natrafiliśmy na krytyczne wąskie gardełko pamięci podczas tworzenia strumienia analitycznego w czasie rzeczywistym przetwarzającego dziesięć milionów pakietów sieciowych na sekundę, gdzie każdy pakiet był reprezentowany jako standardowy obiekt Python. Domyślne przechowywanie oparte na __dict__ zużywało 12GB RAM właśnie na nadmiar obiektów. Powodowało to pauzy w zbieraniu śmieci, które naruszały nasze ściśle określone SLA latencji na poziomie 10 ms.
Rozwiązanie 1: Zapis danych w słowniku. Początkowo rozważaliśmy przechowywanie danych pakietów w prostych instancjach dict. Oferowało to prostotę i serializację JSON bez niestandardowych kodeków, ale profilowanie ujawniło, że tabele haszy słowników nadal wymagały 48 bajtów nadmiaru na obiekt, plus przekierowanie wskaźników, co obniżyło zużycie pamięci tylko o 12%. Brak enkapsulacji metod również rozrzucił logikę biznesową po modułach użytku.
Rozwiązanie 2: Krotki nazwane. Przejście na collections.namedtuple wyeliminowało słowniki dla każdej instancji, korzystając z wsparcia struktury C dla krotek. Chociaż to znacząco zmniejszyło zużycie pamięci, niemutowalność uniemożliwiła nam aktualizację znaczników czasowych pakietów podczas analizy, a niezdolność do dodawania wartości domyślnych lub metod walidacji zmusiła do stosowania niewygodnych wzorców adapterów.
Rozwiązanie 3: Klasy __slots__. Refaktoryzowaliśmy naszą klasę Packet, aby używać stałego przechowywania atrybutów:
class Packet: __slots__ = ('src_ip', 'dst_ip', 'payload', 'timestamp') def __init__(self, src_ip, dst_ip, payload, timestamp): self.src_ip = src_ip self.dst_ip = dst_ip self.payload = payload self.timestamp = timestamp def size(self): return len(self.payload)
To zachowało nasz obiektowy projekt, eliminując całkowicie __dict__. Wybraliśmy to podejście, ponieważ równoważyło efektywność pamięci z konserwowalnością kodu, chociaż musieliśmy jawnie dodać '__weakref__', aby wspierać pamięć podręczną słabych referencji w naszym obiekcie puli.
Wynik. Zużycie pamięci spadło do 4.5GB, co umożliwiło uruchomienie strumienia na standardowym sprzęcie. Dostęp do atrybutu stał się 35% szybszy dzięki bezpośredniemu obliczaniu offsetu zamiast zapytań do tabeli haszy, chociaż musieliśmy refaktoryzować kod do debugowania, który polegał na __dict__ do dynamicznego wstrzykiwania atrybutów.
Jak __slots__ współdziała z wielodziedziczeniem, gdy klasy nadrzędne definiują sprzeczne układy slotów?
Gdy klasa dziecięca dziedziczy z wielu rodziców używających __slots__, Python wymaga, aby połączony układ slotów tworzył spójną liniową sekwencję bez nakładających się nazw. Jeśli rodzice współdzielą nazwy atrybutów w swoich slotach, lub jeśli jeden rodzic używa __slots__, podczas gdy inny korzysta z domyślnego __dict__, interpreter i tak tworzy __dict__ dla dziecka, cicho negując oszczędności pamięci. Dzieje się tak, ponieważ Python buduje jedną tabelę slotów, łącząc sloty rodziców. Kandydaci muszą zrozumieć, że wszyscy rodzice powinni idealnie używać __slots__, a dziecko musi jawnie zadeklarować dodatkowe sloty, aby uniknąć przetwarzania w słowniku.
Dlaczego standardowy moduł pickle nie potrafi odbudować obiektów ze slotami bez niestandardowych metod stanu?
Domyślnie pickle próbuje zapisać i przywrócić stan obiektu za pomocą atrybutu __dict__. Ponieważ klasy ze slotami nie mają tego słownika, chyba że zostanie on jawnie dodany, odczyt obiektu powoduje błąd AttributeError, gdy loader próbuje przypisać do nieistniejących slotów. Rozwiązanie wymaga zaimplementowania __getstate__, aby zwrócić słownik wartości slotów, i __setstate__, aby je przywrócić, lub użycia protokołu __reduce_ex__. Wielu kandydatów przeoczyło, że __slots__ zmienia umowę układu obiektów, zakładając, że pickle automatycznie używa refleksji na opisach slotów.
Czy __slots__ zapobiega dynamicznemu dodawaniu atrybutów instancji w czasie działania?
Tak, ale tylko jeśli żaden rodzic nie zapewnia __dict__, a '__dict__' nie jest jawnie dołączony do listy slotów. Kandydaci często przeoczają, że __slots__ jedynie usuwa atrybut __dict__; jeśli jakakolwiek klasa bazowa zachowuje domyślne przechowywanie słownika, instancje mogą nadal akceptować dowolne atrybuty za pośrednictwem dziedziczonego słownika. Ponadto instancje ze slotami pozostają mutowalne w odniesieniu do istniejących atrybutów, a nadal mogą być modyfikowane na poziomie klasy. Prawdziwa niemutowalność wymaga dodatkowych kroków, takich jak nadpisanie __setattr__, a nie tylko użycie __slots__.