当前位置:  开发笔记 > 编程语言 > 正文

元组比Python中的列表更有效吗?

如何解决《元组比Python中的列表更有效吗?》经验,为你挑选了5个好方法。

在实例化和检索元素时,元组和列表之间是否存在性能差异?



1> dF...:

通常,您可能希望元组稍快一些.但是你绝对应该测试你的特定情况(如果差异可能会影响你的程序的性能 - 记住"过早优化是所有邪恶的根源").

Python使这很容易:timeit是你的朋友.

$ python -m timeit "x=(1,2,3,4,5,6,7,8)"
10000000 loops, best of 3: 0.0388 usec per loop

$ python -m timeit "x=[1,2,3,4,5,6,7,8]"
1000000 loops, best of 3: 0.363 usec per loop

和...

$ python -m timeit -s "x=(1,2,3,4,5,6,7,8)" "y=x[3]"
10000000 loops, best of 3: 0.0938 usec per loop

$ python -m timeit -s "x=[1,2,3,4,5,6,7,8]" "y=x[3]"
10000000 loops, best of 3: 0.0649 usec per loop

所以在这种情况下,元组的实例化速度几乎要快一个数量级,但是对于列表,项目访问实际上要快一些!因此,如果您创建了几个元组并多次访问它们,那么使用列表实际上可能会更快.

当然,如果你想改变一个项目,列表肯定会更快,因为你需要创建一个全新的元组来改变它的一个项目(因为元组是不可变的).


FWIW,列表访问比Python 2中的元组访问更快,但仅仅因为Python/ceval.c中BINARY_SUBSCR中的列表有特殊情况.在Python 3中,优化已经消失,元组访问变得比列表访问快一些.
似乎奇怪的是,元组访问比列表访问慢.但是,在我的Windows 7 PC上的Python 2.7中尝试,差异只有10%,所以不重要.
您使用什么版本的python测试!
还有另一个有趣的测试 - "python -m timeit"x = tuple(xrange(999999))"`vs`python -m timeit"x = list(xrange(999999))"`.正如人们所预料的那样,实现一个元组比一个列表需要更长的时间.
@yoopoo,第一个测试创建了一百万次列表,但第二个创建一个列表并访问它一百万次.`-s"SETUP_CODE"`在实际定时代码之前运行.

2> Raymond Hett..:

摘要

元组往往比几乎每个类别中的列表表现更好:

1)元组可以不断折叠.

2)可以重用元组而不是复制元组.

3)元组是紧凑的,不会过度分配.

4)元组直接引用它们的元素.

元组可以不断折叠

常量元组可以通过Python的窥孔优化器或AST优化器进行预先计算.另一方面,列表从头开始构建:

    >>> from dis import dis

    >>> dis(compile("(10, 'abc')", '', 'eval'))
      1           0 LOAD_CONST               2 ((10, 'abc'))
                  3 RETURN_VALUE   

    >>> dis(compile("[10, 'abc']", '', 'eval'))
      1           0 LOAD_CONST               0 (10)
                  3 LOAD_CONST               1 ('abc')
                  6 BUILD_LIST               2
                  9 RETURN_VALUE 

元组不需要复制

运行tuple(some_tuple)立即返回.由于元组是不可变的,因此不必复制它们:

>>> a = (10, 20, 30)
>>> b = tuple(a)
>>> a is b
True

相反,list(some_list)要求将所有数据复制到新列表:

>>> a = [10, 20, 30]
>>> b = list(a)
>>> a is b
False

元组不会过度分配

由于元组的大小是固定的,因此它可以比需要过度分配以使append()操作有效的列表更紧凑地存储.

这为元组提供了一个很好的空间优势:

>>> import sys
>>> sys.getsizeof(tuple(iter(range(10))))
128
>>> sys.getsizeof(list(iter(range(10))))
200

以下是Objects/listobject.c中的注释,它解释了列表正在执行的操作:

/* This over-allocates proportional to the list size, making room
 * for additional growth.  The over-allocation is mild, but is
 * enough to give linear-time amortized behavior over a long
 * sequence of appends() in the presence of a poorly-performing
 * system realloc().
 * The growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
 * Note: new_allocated won't overflow because the largest possible value
 *       is PY_SSIZE_T_MAX * (9 / 8) + 6 which always fits in a size_t.
 */

元组直接引用它们的元素

对象的引用直接包含在元组对象中.相比之下,列表有一个额外的间接层指向外部指针数组.

这为元组提供了索引查找和解包的小速度优势:

$ python3.6 -m timeit -s 'a = (10, 20, 30)' 'a[1]'
10000000 loops, best of 3: 0.0304 usec per loop
$ python3.6 -m timeit -s 'a = [10, 20, 30]' 'a[1]'
10000000 loops, best of 3: 0.0309 usec per loop

$ python3.6 -m timeit -s 'a = (10, 20, 30)' 'x, y, z = a'
10000000 loops, best of 3: 0.0249 usec per loop
$ python3.6 -m timeit -s 'a = [10, 20, 30]' 'x, y, z = a'
10000000 loops, best of 3: 0.0251 usec per loop

以下是元组(10, 20)的存储方式:

    typedef struct {
        Py_ssize_t ob_refcnt;
        struct _typeobject *ob_type;
        Py_ssize_t ob_size;
        PyObject *ob_item[2];     /* store a pointer to 10 and a pointer to 20 */
    } PyTupleObject;

以下是列表[10, 20]的存储方式:

    PyObject arr[2];              /* store a pointer to 10 and a pointer to 20 */

    typedef struct {
        Py_ssize_t ob_refcnt;
        struct _typeobject *ob_type;
        Py_ssize_t ob_size;
        PyObject **ob_item = arr; /* store a pointer to the two-pointer array */
        Py_ssize_t allocated;
    } PyListObject;

请注意,元组对象直接包含两个数据指针,而列表对象有一个额外的间接层,用于保存两个数据指针的外部数组.


最后,有人把C结构!
使用约50个~100个元素列表列表时,将此结构移动到元组会使查找次数减少多个数量级,以进行多次查找.我相信这是因为一旦你开始使用元组,由于删除你演示的第二层间接,元组的缓存局部性更大.

3> Mark Harriso..:

dis模块反汇编函数的字节代码,有助于查看元组和列表之间的区别.

在这种情况下,您可以看到访问元素会生成相同的代码,但分配元组比分配列表要快得多.

>>> def a():
...     x=[1,2,3,4,5]
...     y=x[2]
...
>>> def b():
...     x=(1,2,3,4,5)
...     y=x[2]
...
>>> import dis
>>> dis.dis(a)
  2           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2)
              6 LOAD_CONST               3 (3)
              9 LOAD_CONST               4 (4)
             12 LOAD_CONST               5 (5)
             15 BUILD_LIST               5
             18 STORE_FAST               0 (x)

  3          21 LOAD_FAST                0 (x)
             24 LOAD_CONST               2 (2)
             27 BINARY_SUBSCR
             28 STORE_FAST               1 (y)
             31 LOAD_CONST               0 (None)
             34 RETURN_VALUE
>>> dis.dis(b)
  2           0 LOAD_CONST               6 ((1, 2, 3, 4, 5))
              3 STORE_FAST               0 (x)

  3           6 LOAD_FAST                0 (x)
              9 LOAD_CONST               2 (2)
             12 BINARY_SUBSCR
             13 STORE_FAST               1 (y)
             16 LOAD_CONST               0 (None)
             19 RETURN_VALUE


呃,只是生成相同的字节码绝对不意味着在C(因此cpu)级别发生相同的操作.尝试使用`__getitem__`创建一个类`ListLike`,它可以做一些非常慢的事情,然后反汇编`x = ListLike((1,2,3,4,5)); y = x [2]`.字节码将更像上面的元组示例而不是列表示例,但您是否真的相信这意味着性能会相似?
虽然你可以通过计算ops得出任何结论的建议被误导,但这确实显示了关键的区别:常量元组在字节码中存储,并且在使用时仅被引用,而列表需要在运行时构建.
字节码的数量,如代码行数,与执行速度(因此效率和性能)几乎没有关系.
这个答案告诉我们Python确认元组常量.很高兴知道!但是当尝试从变量值构建元组或列表时会发生什么?
看来你说有些类型比其他类型更有效.这是有道理的,但列表和元组生成的开销似乎与所涉及的数据类型正交,但需要注意的是它们是相同数据类型的列表和元组.

4> tzot..:

元组是不可变的,更有内存效率; 列表,为了效率,分配内存,以允许附加没有常量reallocs.因此,如果您想在代码中迭代一系列常量值(例如for direction in 'up', 'right', 'down', 'left':),则首选元组,因为这些元组是在编译时预先计算的.

访问速度应该相同(它们都作为连续数组存储在内存中).

但是,当您处理可变数据时,alist.append(item)它更atuple+= (item,)受欢迎.请记住,元组旨在被视为没有字段名称的记录.



5> 小智..:

array如果列表或元组中的所有项目都是相同的C类型,您还应该考虑标准库中的模块.它将占用更少的内存,并且可以更快.


这将占用更少的内存,但访问时间可能会慢一点,而不是更快.访问元素需要将打包值取消装箱到实际整数,这将减慢进程.
推荐阅读
罗文彬2502852027
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有