Python在計算內存時應該注意哪些問題

本篇內容介紹了“Python在計算內存時應該注意哪些問題”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1、計算的是什么?

我們先來看看列表對象的情況：

如圖所示，單獨計算 a 和 b 列表的結果是 36 和 48，然后把它們作為 c 列表的子元素時，該列表的計算結果卻僅僅才 36。(PS：我用的是 32  位解釋器)

如果不使用引用方式，而是直接把子列表寫進去，例如 “d = [[1,2],[1,2,3,4,5]]”，這樣計算 d 列表的結果也還是  36，因為子列表是獨立的對象，在 d 列表中存儲的是它們的 id。

也就是說：getsizeof() 方法在計算列表大小時，其結果跟元素個數相關，但跟元素本身的大小無關。

下面再看看字典的例子：

明顯可以看出，三個字典實際占用的全部內存不可能相等，但是 getsizeof()  方法給出的結果卻相同，這意味著它只關心鍵的數量，而不關心實際的鍵值對是什么內容，情況跟列表相似。

2、“淺計算”與其它問題

有個概念叫“淺拷貝”，指的是 copy() 方法只拷貝引用對象的內存地址，而非實際的引用對象。類比于這個概念，我們可以認為  getsizeof() 是一種“淺計算”。

“淺計算”不關心真實的對象，所以其計算結果只是一個假象。這是一個值得注意的問題，但是注意到這點還不夠，我們還可以發散地思考如下的問題：

• “淺計算”方法的底層實現是怎樣的?

• 為什么 getsizeof() 會采用“淺計算”的方法?

關于第一個問題，getsizeof(x) 方法實際會調用 x 對象的__sizeof__() 魔術方法，對于內置對象來說，這個方法是通過 CPython  解釋器實現的。

我查到這篇文章《Python中對象的內存使用(一)》，它分析了 CPython 源碼，最終定位到的核心代碼是這一段：

/*longobject.c*/  static Py_ssize_t int___sizeof___impl(PyObject *self) {     Py_ssize_t res;      res = offsetof(PyLongObject, ob_digit) + Py_ABS(Py_SIZE(self))*sizeof(digit);     return res; }

我看不懂這段代碼，但是可以知道的是，它在計算 Python 對象的大小時，只跟該對象的結構體的屬性相關，而沒有進一步作“深度計算”。

對于 CPython 的這種實現，我們可以注意到兩個層面上的區別：

• 字節增大：int 類型在 C 語言中只占到 4 個字節，但是在 Python 中，int  其實是被封裝成了一個對象，所以在計算其大小時，會包含對象結構體的大小。在 32 位解釋器中，getsizeof(1) 的結果是 14 個字節，比數字本身的 4  字節增大了。

• 字節減少：對于相對復雜的對象，例如列表和字典，這套計算機制由于沒有累加內部元素的占用量，就會出現比真實占用內存小的結果。

由此，我有一個不成熟的猜測：基于“一切皆是對象”的設計原則，int 及其它基礎的 C 數據類型在 Python  中被套上了一層“殼”，所以需要一個方法來計算它們的大小，也即是 getsizeof()。

官方文檔中說“All built-in objects will return correct results”  [1]，指的應該是數字、字符串和布爾值之類的簡單對象。但是不包括列表、元組和字典等在內部存在引用關系的類型。

為什么不推廣到所有內置類型上呢?我未查到這方面的解釋，若有知情的同學，煩請告知。

3、“深計算”與其它問題

與“淺計算”相對應，我們可以定義出一種“深計算”。對于前面的兩個例子，“深計算”應該遍歷每個內部元素以及可能的子元素，累加計算它們的字節，最后算出總的內存大小。

那么，我們應該注意的問題有：

• 是否存在“深計算”的方法/實現方案?

• 實現“深計算”時應該注意什么?

Stackoverflow 網站上有個年代久遠的問題“How do I determine the size of an object in  Python?” [2]，實際上問的就是如何實現“深計算”的問題。

有不同的開發者貢獻了兩個項目：pympler 和 pysize ：第一個項目已發布在 Pypi 上，可以“pip install  pympler”安裝;第二個項目爛尾了，作者也沒發布到 Pypi 上(注：Pypi 上已有個 pysize 庫，是用來做格式轉化的，不要混淆)，但是可以在  Github 上獲取到其源碼。

對于前面的兩個例子，我們可以拿這兩個項目分別測試一下：

單看數值的話，pympler 似乎確實比 getsizeof() 合理多了。

再看看 pysize，直接看測試結果是(獲取其源碼過程略)：

64 118 190 206 300281 30281

可以看出，它比 pympler 計算的結果略小。就兩個項目的完整度、使用量與社區貢獻者規模來看，pympler 的結果似乎更為可信。

那么，它們分別是怎么實現的呢?那微小的差異是怎么導致的?從它們的實現方案中，我們可以學習到什么呢?

pysize 項目很簡單，只有一個核心方法：

def get_size(obj, seen=None):     """Recursively finds size of objects in bytes"""     size = sys.getsizeof(obj)     if seen is None:         seen = set()     obj_id = id(obj)     if obj_id in seen:         return 0     # Important mark as seen *before* entering recursion to gracefully handle     # self-referential objects     seen.add(obj_id)     if hasattr(obj, '__dict__'):         for cls in obj.__class__.__mro__:             if '__dict__' in cls.__dict__:                 d = cls.__dict__['__dict__']                 if inspect.isgetsetdescriptor(d) or inspect.ismemberdescriptor(d):                     size += get_size(obj.__dict__, seen)                 break     if isinstance(obj, dict):         size += sum((get_size(v, seen) for v in obj.values()))         size += sum((get_size(k, seen) for k in obj.keys()))     elif hasattr(obj, '__iter__') and not isinstance(obj, (str, bytes, bytearray)):         size += sum((get_size(i, seen) for i in obj))      if hasattr(obj, '__slots__'): # can have __slots__ with __dict__         size += sum(get_size(getattr(obj, s), seen) for s in obj.__slots__ if hasattr(obj, s))      return size

除去判斷__dict__和  __slots__屬性的部分(針對類對象)，它主要是對字典類型及可迭代對象(除字符串、bytes、bytearray)作遞歸的計算，邏輯并不復雜。

以 [1,2] 這個列表為例，它先用 sys.getsizeof() 算出 36 字節，再計算內部的兩個元素得 14*2=28 字節，最后相加得到 64  字節。

相比之下，pympler 所考慮的內容要多很多，入口在這：

def asizeof(self, *objs, **opts):       '''Return the combined size of the given objects          (with modified options, see method **set**).       '''       if opts:           self.set(**opts)       self.exclude_refs(*objs)  # skip refs to objs       return sum(self._sizer(o, 0, 0, None) for o in objs)

它可以接受多個參數，再用 sum() 方法合并。所以核心的計算方法其實是 _sizer()。但代碼很復雜，繞來繞去像一座迷宮：

def _sizer(self, obj, pid, deep, sized):  # MCCABE 19         '''Size an object, recursively.         '''         s, f, i = 0, 0, id(obj)         if i not in self._seen:             self._seen[i] = 1         elif deep or self._seen[i]:             # skip obj if seen before             # or if ref of a given obj             self._seen.again(i)             if sized:                 s = sized(s, f, name=self._nameof(obj))                 self.exclude_objs(s)             return s  # zero         else:  # deep == seen[i] == 0             self._seen.again(i)         try:             k, rs = _objkey(obj), []             if k in self._excl_d:                 self._excl_d[k] += 1             else:                 v = _typedefs.get(k, None)                 if not v:  # new typedef                     _typedefs[k] = v = _typedef(obj, derive=self._derive_,                                                      frames=self._frames_,                                                       infer=self._infer_)                 if (v.both or self._code_) and v.kind is not self._ign_d:                     # 貓注：這里計算 flat size                     s = f = v.flat(obj, self._mask)  # flat size                     if self._profile:                         # profile based on *flat* size                         self._prof(k).update(obj, s)                     # recurse, but not for nested modules                     if v.refs and deep < self._limit_ \                               and not (deep and ismodule(obj)):                         # add sizes of referents                         z, d = self._sizer, deep + 1                         if sized and deep < self._detail_:                             # use named referents                             self.exclude_objs(rs)                             for o in v.refs(obj, True):                                 if isinstance(o, _NamedRef):                                     r = z(o.ref, i, d, sized)                                     r.name = o.name                                 else:                                     r = z(o, i, d, sized)                                     r.name = self._nameof(o)                                 rs.append(r)                                 s += r.size                         else:  # just size and accumulate                             for o in v.refs(obj, False):                                 # 貓注：這里遞歸計算 item size                                 s += z(o, i, d, None)                         # deepest recursion reached                         if self._depth < d:                             self._depth = d                 if self._stats_ and s > self._above_ > 0:                     # rank based on *total* size                     self._rank(k, obj, s, deep, pid)         except RuntimeError:  # XXX RecursionLimitExceeded:             self._missed += 1         if not deep:             self._total += s  # accumulate         if sized:             s = sized(s, f, name=self._nameof(obj), refs=rs)             self.exclude_objs(s)         return s

它的核心邏輯是把每個對象的 size 分為兩部分：flat size 和 item size。

計算 flat size 的邏輯在：

def flat(self, obj, mask=0):         '''Return the aligned flat size.         '''         s = self.base         if self.leng and self.item > 0:  # include items             s += self.leng(obj) * self.item         # workaround sys.getsizeof (and numpy?) bug ... some         # types are incorrectly sized in some Python versions         # (note, isinstance(obj, ()) == False)         # 貓注：不可 sys.getsizeof 的，則用上面邏輯，可以的，則用下面邏輯         if not isinstance(obj, _getsizeof_excls):             s = _getsizeof(obj, s)         if mask:  # align             s = (s + mask) & ~mask         return s

這里出現的 mask 是為了作字節對齊，默認值是 7，該計算公式表示按 8 個字節對齊。對于 [1,2] 列表，會算出 (36+7)&~7=40  字節。同理，對于單個的 item，比如列表中的數字 1，sys.getsizeof(1) 等于 14，而 pympler 會算成對齊的數值 16，所以匯總起來是  40+16+16=72 字節。這就解釋了為什么 pympler 算的結果比 pysize 大。

字節對齊一般由具體的編譯器實現，而且不同的編譯器還會有不同的策略，理論上 Python 不應關心這么底層的細節，內置的 getsizeof()  方法就沒有考慮字節對齊。

在不考慮其它 edge cases 的情況下，可以認為 pympler 是在 getsizeof() 的基礎上，既考慮了遍歷取引用對象的  size，又考慮到了實際存儲時的字節對齊問題，所以它會顯得更加貼近現實。

“Python在計算內存時應該注意哪些問題”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！