__slots__メカニズムは、動的属性ストレージのために、インスタンスごとに__dict__ハッシュテーブルを割り当てるデフォルトのオブジェクトモデルに関連する大きなメモリオーバーヘッドに対処するためにPython 2.2で導入されました。問題は、高スケールのアプリケーションで、何百万ものオブジェクトが辞書の管理だけで数百メガバイトのRAMを消費し、メモリプレッシャーやキャッシュミスが発生し、パフォーマンスが低下することです。この解決策は、文字列の反復可能なオブジェクトを含むクラス変数として__slots__を宣言することにより、属性のために固定C-配列オフセットを予約するようにインタープリターに指示します。これにより、ハッシュルックアップを排除し、明示的に要求されない限り__dict__と__weakref__スロットを排除します。
この最適化により、インスタンスごとのメモリフットプリントが約40〜50%削減され、ハッシングオーバーヘッドを避けることで属性アクセスが高速化されます。また、明示的に含めない限り__weakref__の作成を防ぎ、オブジェクトのサイズをさらに削減します。ただし、剛性を導入します：インスタンスは動的に新しい属性を得ることができず、クラス階層は辞書ストレージに静かに戻らないようにスロットの一貫性を維持する必要があります。
私たちは、1秒間に1000万のネットワークパケットを処理するリアルタイム分析パイプラインを開発しているときに、重要なメモリボトルネックに直面しました。各パケットは標準のPythonオブジェクトとして表現されていました。デフォルトの__dict__ベースのストレージは、オブジェクトのオーバーヘッドだけで12GBのRAMを消費していました。これにより、厳格な10msのレイテンシSLAに違反するガーベジコレクションの一時停止が発生しました。
解決策1: 辞書ベースのレコード。 初めは、パケットデータをプレーンなdictインスタンスに保存することを考慮していました。これにより、シンプルさとJSONシリアル化をカスタムコーデックなしで提供されましたが、プロファイリングの結果、辞書のハッシュテーブルはオブジェクトごとに48バイトのオーバーヘッドとポインタ間接参照が必要で、メモリ使用量は12%しか削減できませんでした。また、メソッドのカプセル化が欠如していたため、ビジネスロジックがユーティリティモジュール全体に散らばっていました。
解決策2: 名前付きタプル。 collections.namedtupleに切り替えることで、タプルのC構造のバックによりインスタンスごとの辞書が排除されました。これによりメモリが大幅に削減されましたが、不変性のため、分析中にパケットのタイムスタンプを更新することができず、デフォルト値や検証メソッドを追加できないため、適応パターンが不自然になりました。
解決策3: __slots__クラス。 私たちは、固定属性ストレージを使用するようにPacketクラスをリファクタリングしました：
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)
これは、__dict__を完全に排除しつつ、オブジェクト指向設計を維持しました。このアプローチを選んだのは、メモリ効率とコードメンテナンス性のバランスが取れていたからですが、オブジェクトプールの弱い参照キャッシュをサポートするために、明示的に'__weakref__'を含める必要がありました。
結果。 メモリフットプリントは4.5GBに縮小され、パイプラインは一般的なハードウェアで実行可能になりました。属性アクセスはハッシュテーブルのプローブではなく、直接オフセット計算によって35%早くなりましたが、動的属性の注入に__dict__を依存していたデバッグコードをリファクタリングする必要がありました。
__slots__は、親クラスが競合するスロットレイアウトを定義する場合、複数の継承とどのように相互作用しますか？
子クラスが__slots__を使用して複数の親から継承する場合、Pythonは結合されたスロットレイアウトが重複する名前なしに一貫した線形シーケンスを形成する必要があります。親がスロット内で属性名を共有する場合、または1つの親が__slots__を使用し、もう1つがデフォルトの__dict__を使用している場合、インタープリターは子に対して__dict__を作成し、メモリの節約を静かに無効にします。これは、Pythonが親のスロットを連結して単一のスロットテーブルを構築するために発生します。候補者は、すべての親が理想的には__slots__を使用する必要があり、子が辞書のフォールバックを避けるために追加のスロットを明示的に宣言する必要があることを理解する必要があります。
なぜ標準のpickleモジュールは、カスタム状態メソッドなしでスロットオブジェクトを再構築できないのですか？
デフォルトでは、pickleはオブジェクトの状態をその__dict__属性を介して保存および復元しようとします。スロットクラスは、明示的に追加されない限り、この辞書を持たないため、ローダーが存在しないスロットに割り当てようとした場合、unpicklingはAttributeErrorを引き起こします。この解決策には、スロット値の辞書を返すために__getstate__を実装し、それを復元するために__setstate__を使用するか、__reduce_ex__プロトコルを使用する必要があります。多くの候補者は、__slots__がオブジェクトレイアウト契約を変更することを見落とし、pickleがスロット記述子に対するリフレクションを自動的に使用すると仮定しています。
__slots__は、実行時にインスタンス属性が動的に追加されるのを防ぎますか？
はい、しかし親クラスが__dict__を提供せず、スロットリストに'__dict__'が明示的に含まれていない場合のみです。候補者は、__slots__が__dict__属性を単に削除することを見落としがちですが、いずれかの基底クラスがデフォルトの辞書ストレージを保持している場合、インスタンスはその継承された辞書を介して任意の属性を受け入れることができます。さらに、スロットインスタンスは既存の属性に関しては可変性を維持し、クラスレベルでモンキーパッチを施すことができます。本当の不変性が必要な場合は、__setattr__をオーバーライドするなどの追加のステップが必要であり、単に__slots__を使用するだけでは済みません。