一文带你了解Python在计算内存时应该注意的问题！

最新推荐文章于 2024-04-10 10:04:16 发布

AI科学小老师

最新推荐文章于 2024-04-10 10:04:16 发布

阅读量198

点赞数

本文链接：https://blog.csdn.net/weixin_41663412/article/details/104977381

版权

本文探讨了Python中`getsizeof()`方法在计算内存时的局限性，将其称为“浅计算”。通过实例分析，揭示了`getsizeof()`在处理列表和字典时只考虑对象数量，而不考虑实际内容大小的问题。文章还介绍了“深计算”的概念，并对比了两个第三方库pympler和pysize在实现深计算上的差异，分析了字节对齐等因素对结果的影响。最后，文章讨论了Python官方文档中提供的深计算示例，并对未来可能出现的深计算方法进行了展望。

摘要由CSDN通过智能技术生成

个人博客导航页（点击右侧链接即可打开个人博客）：大牛带你入门技术栈

附

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]，指的应该是数字、字符串和布尔值之类的简单对象。但是不包括列表、元组和字典等在内部存在引