Het __slots__ mechanisme werd geïntroduceerd in Python 2.2 om het aanzienlijke geheugenverbruik aan te pakken dat gepaard gaat met het standaard objectmodel, dat een per-instantie __dict__ hash-tabel toewijst voor dynamische attributenopslag. Het probleem doet zich voor in toepassingen met hoge schaal, waar miljoenen objecten honderden megabytes RAM verbruiken alleen al voor de dictionary-boekhouding, wat geheugenproblemen en cache-misses veroorzaakt die de prestaties verminderen. De oplossing omvat het declareren van __slots__ als een klassevariabele die een iterable van strings bevat, die de interpreter instrueren om vaste C-array-offsets voor attributen te reserveren in plaats van hash-zoekopdrachten, waardoor de __dict__ en __weakref__ slots worden geëlimineerd, tenzij expliciet aangevraagd.
Deze optimalisatie vermindert de geheugendruk per instantie met ongeveer 40-50% en versnelt de toegang tot attributen door hashing overhead te vermijden. Het voorkomt ook de creatie van __weakref__, tenzij expliciet inbegrepen, wat de objectgrootte verder vermindert. Echter, het introduceert rigide: instanties kunnen dynamisch geen nieuwe attributen verkrijgen, en klassenhiërarchieën moeten de consistentie van slots handhaven om stilletjes terugvallen op dictionary-opslag te voorkomen.
We stonden voor een kritieke geheugenflessenhals tijdens de ontwikkeling van een realtime analysetrechter die tien miljoen netwerkpakketten per seconde verwerkte, waarbij elk pakket werd weergegeven als een standaard Python object. De standaard opslag op basis van __dict__ verbruikte 12GB RAM alleen voor de objectoverhead. Dit zorgde voor pauzes in de garbage collection die onze strikte 10ms latentie SLA schonden.
Oplossing 1: Dictionary-gebaseerde records. We overwoogen aanvankelijk om pakketgegevens op te slaan in gewone dict instanties. Dit bood eenvoud en JSON serialisatie zonder aangepaste codecs, maar profilering toonde aan dat de hash-tabellen van dictionaries nog steeds 48 bytes overhead per object vereisten plus pointer-indirectie, wat het geheugengebruik met slechts 12% verminderde. Het gebrek aan methode-encapsulatie verspreidde ook de bedrijfslogica over hulpprogrammamodules.
Oplossing 2: Genoemde tuples. Overschakelen naar collections.namedtuple elimineerde per-instantie dictionaries met de C-structuur van tuples. Hoewel dit het geheugen aanzienlijk verminderde, voorkwam de onveranderlijkheid dat we pakketstempels tijdens de analyse konden bijwerken, en de onmogelijkheid om standaardwaarden of validatiemethoden toe te voegen dwong ons tot onhandige adapterpatronen.
Oplossing 3: __slots__ klassen. We refactorde onze Packet klasse om vaste attributenopslag te gebruiken:
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)
Dit behield ons object-georiënteerde ontwerp terwijl __dict__ volledig werd verwijderd. We kozen deze benadering omdat deze de geheugenefficiëntie in evenwicht bracht met de onderhoudbaarheid van de code, hoewel we '__weakref__' expliciet moesten opnemen om de zwakke referentie-cache van onze objectpool te ondersteunen.
Het resultaat. De geheugendruk daalde tot 4.5GB, waardoor de pijplijn op commodity hardware kon draaien. De toegang tot attributen werd 35% sneller door directe offsetberekening in plaats van hashtable-probes, hoewel we de debuggingcode moesten refactoren die afhankelijk was van __dict__ voor dynamische attributeninjectie.
Hoe interageert __slots__ met meervoudige overerving wanneer bovenliggende klassen conflicterende slot lay-outs definiëren?
Wanneer een kindklasse van meerdere ouders erft met behulp van __slots__, vereist Python dat de gecombineerde slot lay-out een consistente lineaire volgorde vormt zonder overlappende namen. Als ouders attribuutnamen in hun slots delen, of als de ene ouder __slots__ gebruikt terwijl een andere de standaard __dict__ gebruikt, maakt de interpreter toch een __dict__ voor het kind, wat stilletjes geheugenbesparingen tenietdoet. Dit gebeurt omdat Python een enkele slottabel constructeert door de slots van ouders samen te voegen. Kandidaten moeten begrijpen dat alle ouders idealiter __slots__ moeten gebruiken, en het kind moet expliciet extra slots declareren om terugval naar dictionary op te vermijden.
Waarom mislukt de standaard pickle module erin om objecten met slots zonder aangepaste statemethoden te reconstrueren?
Standaard probeert pickle de status van een object op te slaan en te herstellen via zijn __dict__ attribuut. Aangezien geslotene klassen deze dictionary niet hebben, tenzij expliciet toegevoegd, geeft unpicklen een AttributeError wanneer de loader probeert toe te wijzen aan niet-bestaande slots. De oplossing vereist het implementeren van __getstate__ om een dictionary van slotwaarden terug te geven en __setstate__ om deze te herstellen, of het gebruik van het __reduce_ex__ protocol. Veel kandidaten over het hoofd zien dat __slots__ het objectlay-outcontract verandert, in de veronderstelling dat pickle automatisch reflectie op slotdescriptoren toepast.
Voorkomt __slots__ dat instantiesattributen dynamisch tijdens runtime worden toegevoegd?
Ja, maar alleen als geen enkele bovenliggende klasse een __dict__ biedt en '__dict__' niet expliciet in de slots-lijst is opgenomen. Kandidaten missen vaak dat __slots__ alleen het __dict__ attribuut verwijdert; als een basis klasse de standaard dictionary-opslag behoudt, kunnen instanties nog steeds willekeurige attributen accepteren via die geërfde dictionary. Bovendien blijven geslotene instanties wijzigbaar met betrekking tot bestaande attributen, en ze kunnen nog steeds op klasseniveau monkey-patched worden. Werkelijke onveranderlijkheid vereist aanvullende stappen zoals het overschrijven van __setattr__, niet alleen het gebruik van __slots__.