Python 浅析列表的变长变短

来源:Lin_R 链接:

https://segmentfault.com/a/1190000017221754

前言

Python 的列表(list)是一个非常灵活的数组,可以随意调整长度。正是因为这种便利,使得我们会情不自禁地去修改数组以满足我们的需求,其中相比于, 等等而言, 用法更常见。

有像这样使用:

也有像这样使用的:

这样用很开心,也很满足。

但其实只要遇到能够动态修改数据长度场景,我们都应该马上反应过来一点,那就是内存管理的问题。

如果运行效率和便捷性同时满足的话,那简直就是大大的福音呀。

然而,上帝为你开启一扇窗的同时肯定也已经关上了一扇门了!

吝啬的初始化

深受预分配知识的熏陶,我们也是觉得 list 在初始化是有分配一定的长度的,要不然每次都申请内存那得多 ”low“ 啊。

然后实际上 list 真的就是这么 ”low“:

我们的猜测是,list 在定义之后,会预先分配好一个一定大小的池用来塞数据,以避免动不动就申请内存。

但是在上面的实验看出,一个成员的列表,比一个空列表,长度仅仅只是大了 8 字节,如果真的存在这样一个预分配的池,那么在预分配个数之内添加成员,两者的内存大小应该是保持不变才对。

所以可以猜测这块 应该是没有这样的一个预分配内存池。这里需要来个实锤

当我们在执行 时,实际上只做了两件事:

根据成员的数目,构建相应长度的空列表;(上述代码)

一个个将这些成员塞进去;

可能有童鞋会觉得,在塞成员的那一步,说不定会触发什么机制使它变大?

很可惜,因为初始化用的方法是 , 所以这里是木有的触发什么机制,只是简单的数组成员赋值而已:

所以整个 list 的初始化,还真的就是木有预分配的内存池,直接按需申请,一个萝卜一个坑,实在得狠;

可变长的关键

初始化过程是这样还可以理解,如果运行中还这样的话,那就有点说不过去了。

试想下,在文章开头用 的例子中,如果每 一个元素就申请一次内存,那么 可能要被吐槽到怀疑人生了, 所以很明显,在对于内存的申请,它还是有自己的套路的。

在 里面,不管是 、 还是 ,都会遇到 ,故名思义,这个函数就是用来调整 list 对象的内存占用的。

在上面的代码中,频繁看到两个名词:和, 这里需要解释下,并不是增加/减少的个数,而是增加/减少之后的成员总数目。比方说:

上面的 触发 时, 是 3 + 1, 而不是 1;这边比较重要,因为在 这类减少列表成员时候,就是传入缩减后的总数目。

在 list 的结构定义中,关于长度的定义有两个,分别是 ,

它们之间的关系就是:

所以 就很好理解了,这个就是新的总坑数。

当名词含义理解得差不多时,我们就能顺藤摸瓜知道一个列表在 之后,大小会变成怎样?

方法其实从上面注释和代码都说得很明白了,这里再简单整理下:

先确定一个基数:;

判断下 有没有超过 , 如果超过了,直接报错;

最终确定新的总坑数是:, 如果 是 0, 那么总坑数直接为 0 ;

下面演示下:

开始简单的代入法一步步算:

其中:

通过上面的表格,应该比较清楚看到什么时候会触发改变 ,并且当触发时它们是如何计算的。为什么我们需要这样关注 ?理由很简单,因为这个值决定了整个 list 的动态内存的占用大小;

扩容是这样,缩容也是照猫画虎。反正都是算出新的 allocated, 然后由 来处理。

总结

综上所述,在一些明确列表成员或者简单处理再塞入列表的情况下,我们不应该再用下面的方式:

而是应该用更加和 更加高效的列表推导式:。

(完)

看完本文有收获?请转发分享给更多人

关注「Python那些事」,做全栈开发工程师

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181210B0750B00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券