Python在计算内存时应该注意的问题?

开发 后端
我之前的一篇文章,带大家揭晓了 Python 在给内置对象分配内存时的 5 个奇怪而有趣的小秘密。文中使用了sys.getsizeof()来计算内存,但是用这个方法计算时,可能会出现意料不到的问题。

 我之前的一篇文章,带大家揭晓了 Python 在给内置对象分配内存时的 5 个奇怪而有趣的小秘密。文中使用了sys.getsizeof()来计算内存,但是用这个方法计算时,可能会出现意料不到的问题。

[[317078]]

文档中关于这个方法的介绍有两层意思:

  • 该方法用于获取一个对象的字节大小(bytes)
  • 它只计算直接占用的内存,而不计算对象内所引用对象的内存

也就是说,getsizeof() 并不是计算实际对象的字节大小,而是计算“占位对象”的大小。如果你想计算所有属性以及属性的属性的大小,getsizeof() 只会停留在第一层,这对于存在引用的对象,计算时就不准确。

例如列表 [1,2],getsizeof() 不会把列表内两个元素的实际大小算上,而只是计算了对它们的引用。举一个形象的例子,我们把列表想象成一个箱子,把它存储的对象想象成一个个球,现在箱子里有两张纸条,写上了球 1 和球 2 的地址(球不在箱子里),getsizeof() 只是把整个箱子称重(含纸条),而没有根据纸条上地址,找到两个球一起称重。

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 源码,最终定位到的核心代码是这一段:

 

  1. /*longobject.c*/ 
  2.  
  3. static Py_ssize_t 
  4. int___sizeof___impl(PyObject *self) 
  5.     Py_ssize_t res; 
  6.  
  7.     res = offsetof(PyLongObject, ob_digit) + Py_ABS(Py_SIZE(self))*sizeof(digit); 
  8.     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,直接看测试结果是(获取其源码过程略):

 

  1. 64 
  2. 118 
  3. 190 
  4. 206 
  5. 300281 
  6. 30281 

可以看出,它比 pympler 计算的结果略小。就两个项目的完整度、使用量与社区贡献者规模来看,pympler 的结果似乎更为可信。

那么,它们分别是怎么实现的呢?那微小的差异是怎么导致的?从它们的实现方案中,我们可以学习到什么呢?

pysize 项目很简单,只有一个核心方法:

 

  1. def get_size(obj, seen=None): 
  2.     """Recursively finds size of objects in bytes""" 
  3.     size = sys.getsizeof(obj) 
  4.     if seen is None: 
  5.         seen = set() 
  6.     obj_id = id(obj) 
  7.     if obj_id in seen: 
  8.         return 0 
  9.     # Important mark as seen *before* entering recursion to gracefully handle 
  10.     # self-referential objects 
  11.     seen.add(obj_id) 
  12.     if hasattr(obj, '__dict__'): 
  13.         for cls in obj.__class__.__mro__: 
  14.             if '__dict__' in cls.__dict__: 
  15.                 d = cls.__dict__['__dict__'
  16.                 if inspect.isgetsetdescriptor(d) or inspect.ismemberdescriptor(d): 
  17.                     size += get_size(obj.__dict__, seen) 
  18.                 break 
  19.     if isinstance(obj, dict): 
  20.         size += sum((get_size(v, seen) for v in obj.values())) 
  21.         size += sum((get_size(k, seen) for k in obj.keys())) 
  22.     elif hasattr(obj, '__iter__'and not isinstance(obj, (str, bytes, bytearray)): 
  23.         size += sum((get_size(i, seen) for i in obj)) 
  24.  
  25.     if hasattr(obj, '__slots__'): # can have __slots__ with __dict__ 
  26.         size += sum(get_size(getattr(obj, s), seen) for s in obj.__slots__ if hasattr(obj, s)) 
  27.  
  28.     return size 

除去判断__dict__和 __slots__属性的部分(针对类对象),它主要是对字典类型及可迭代对象(除字符串、bytes、bytearray)作递归的计算,逻辑并不复杂。

以 [1,2] 这个列表为例,它先用 sys.getsizeof() 算出 36 字节,再计算内部的两个元素得 14*2=28 字节,最后相加得到 64 字节。

相比之下,pympler 所考虑的内容要多很多,入口在这:

 

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

它可以接受多个参数,再用 sum() 方法合并。所以核心的计算方法其实是 _sizer()。但代码很复杂,绕来绕去像一座迷宫:

 

  1. def _sizer(self, obj, pid, deep, sized):  # MCCABE 19 
  2.         '''Size an object, recursively. 
  3.         ''
  4.         s, f, i = 0, 0, id(obj) 
  5.         if i not in self._seen: 
  6.             self._seen[i] = 1 
  7.         elif deep or self._seen[i]: 
  8.             # skip obj if seen before 
  9.             # or if ref of a given obj 
  10.             self._seen.again(i) 
  11.             if sized: 
  12.                 s = sized(s, f, name=self._nameof(obj)) 
  13.                 self.exclude_objs(s) 
  14.             return s  # zero 
  15.         else:  # deep == seen[i] == 0 
  16.             self._seen.again(i) 
  17.         try: 
  18.             k, rs = _objkey(obj), [] 
  19.             if k in self._excl_d: 
  20.                 self._excl_d[k] += 1 
  21.             else
  22.                 v = _typedefs.get(k, None) 
  23.                 if not v:  # new typedef 
  24.                     _typedefs[k] = v = _typedef(obj, derive=self._derive_, 
  25.                                                      frames=self._frames_, 
  26.                                                       infer=self._infer_) 
  27.                 if (v.both or self._code_) and v.kind is not self._ign_d: 
  28.                     # 猫注:这里计算 flat size 
  29.                     s = f = v.flat(obj, self._mask)  # flat size 
  30.                     if self._profile: 
  31.                         # profile based on *flat* size 
  32.                         self._prof(k).update(obj, s) 
  33.                     # recurse, but not for nested modules 
  34.                     if v.refs and deep < self._limit_ \ 
  35.                               and not (deep and ismodule(obj)): 
  36.                         # add sizes of referents 
  37.                         z, d = self._sizer, deep + 1 
  38.                         if sized and deep < self._detail_: 
  39.                             # use named referents 
  40.                             self.exclude_objs(rs) 
  41.                             for o in v.refs(obj, True): 
  42.                                 if isinstance(o, _NamedRef): 
  43.                                     r = z(o.ref, i, d, sized) 
  44.                                     r.name = o.name 
  45.                                 else
  46.                                     r = z(o, i, d, sized) 
  47.                                     r.name = self._nameof(o) 
  48.                                 rs.append(r) 
  49.                                 s += r.size 
  50.                         else:  # just size and accumulate 
  51.                             for o in v.refs(obj, False): 
  52.                                 # 猫注:这里递归计算 item size 
  53.                                 s += z(o, i, d, None) 
  54.                         # deepest recursion reached 
  55.                         if self._depth < d: 
  56.                             self._depth = d 
  57.                 if self._stats_ and s > self._above_ > 0: 
  58.                     # rank based on *total* size 
  59.                     self._rank(k, obj, s, deep, pid) 
  60.         except RuntimeError:  # XXX RecursionLimitExceeded: 
  61.             self._missed += 1 
  62.         if not deep: 
  63.             self._total += s  # accumulate 
  64.         if sized: 
  65.             s = sized(s, f, name=self._nameof(obj), refs=rs) 
  66.             self.exclude_objs(s) 
  67.         return s 

它的核心逻辑是把每个对象的 size 分为两部分:flat size 和 item size。

计算 flat size 的逻辑在:

 

  1. def flat(self, obj, mask=0): 
  2.         '''Return the aligned flat size
  3.         ''
  4.         s = self.base 
  5.         if self.leng and self.item > 0:  # include items 
  6.             s += self.leng(obj) * self.item 
  7.         # workaround sys.getsizeof (and numpy?) bug ... some 
  8.         # types are incorrectly sized in some Python versions 
  9.         # (note, isinstance(obj, ()) == False
  10.         # 猫注:不可 sys.getsizeof 的,则用上面逻辑,可以的,则用下面逻辑 
  11.         if not isinstance(obj, _getsizeof_excls): 
  12.             s = _getsizeof(obj, s) 
  13.         if mask:  # align 
  14.             s = (s + mask) & ~mask 
  15.         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,又考虑到了实际存储时的字节对齐问题,所以它会显得更加贴近现实。

4、小结

getsizeof() 方法的问题是显而易见的,我创造了一个“浅计算”概念给它。这个概念借鉴自 copy() 方法的“浅拷贝”,同时对应于 deepcopy() “深拷贝”,我们还能推理出一个“深计算”。

前面展示了两个试图实现“深计算”的项目(pysize+pympler),两者在浅计算的基础上,深入地求解引用对象的大小。pympler 项目的完整度较高,代码中有很多细节上的设计,比如字节对齐。

Python 官方团队当然也知道 getsizeof() 方法的局限性,他们甚至在文档中加了一个链接 [3],指向了一份实现深计算的示例代码。那份代码比 pysize 还要简单(没有考虑类对象的情况)。

未来 Python 中是否会出现深计算的方法,假设命名为 getdeepsizeof() 呢?这不得而知了。

本文的目的是加深对 getsizeof() 方法的理解,区分浅计算与深计算,分析两个深计算项目的实现思路,指出几个值得注意的问题。

读完这里,希望你也能有所收获。若有什么想法,欢迎一起交流。

责任编辑:华轩 来源: Python猫
相关推荐

2021-01-25 17:24:13

云计算云服务器云安全

2011-07-27 10:53:47

交换机

2012-05-22 09:41:12

Python

2018-04-17 11:30:03

云计算IaaS公共云

2010-02-03 16:32:13

2018-08-10 07:04:47

数据中心运维云计算

2020-08-17 08:00:54

计算机IT互联网

2010-08-23 09:35:12

云计算SaaS

2021-01-13 10:33:57

云计算云迁移云平台

2011-07-15 08:52:45

UML工具

2010-08-30 09:22:13

DIV高度自适应

2017-11-07 21:05:43

机房配电柜配电箱

2010-06-04 14:42:25

2012-09-20 15:11:31

Unix服务器

2011-07-08 14:09:51

iPhone UI

2009-03-19 18:36:49

虚拟化Vmwareesx

2024-10-08 09:43:44

golang高并发加锁事务

2020-02-27 09:39:42

云安全云计算网络安全

2009-07-01 14:49:52

JSP空间租用

2010-01-06 16:41:40

解析JSON
点赞
收藏

51CTO技术栈公众号