要点概论
1. 时间开销
2. 空间开销
3. Python 程序的时间复杂度实例
4. 程序实现和效率陷阱
1. 时间开销
在考虑 python 程序的时间开销时，有一个问题特别需要注意：python 程序中的很多基本操作不是常量时间的。
下面是一些情况：
1）基本算术运算时常量时间操作【注：】，逻辑运算时常量时间运算。
2）组合对象的操作有些是常量时间的，有些不是，例如：
① 复制和切片操作通常需要线性时间（与长度有关，是 O(n)）时间操作。
② list 和 tuple 的元素访问和元素赋值，是常量时间的。
③ dict 操作的情况比较复杂【补充一个链接地址】。
3）字符串也应该看作组合对象，但许多操作不是常量时间的。
4）创建对象也需要付出空间和时间，空间和时间代价都与对象大小有关。
对于组合对象，这里可能有需要构造的一个个元素，元素有大小问题，
整体看还有元素个数问题。通常应看作线性时间和线性空间操作（以元素个数作为规模）。
Python 结构和操作的效率问题：
1）构造新结构，如构造 list ，set 等。构造新的空结构（空表，空集合等）是常量时间操作，
而构造一个包含 n 个元素的结构，则至少需要 O(n) 时间。统计说明，分配长度为 n 个
元素的存储块的时间代价是 O(n)。
2）一些 list 操作的效率：表元素访问的元素修改是常量时间操作，但一般的加入、
删除元素操作（即使只加入一个元素）都是 O(n) 时间操作。
3） 字典 dict 操作的效率：主要操作是加入新的键值对和基于键查找关联值。
它们的最坏情况复杂度是 O(n) ，但平均复杂度是 O(l) 。
也就是说，一般而言字典操作的效率很高，但偶然也会出现效率低的情况。
2. 空间开销
在程序里使用任何类型的对象，都需要付出空间的代价。建立一个表或者元组，至少要占用元素个数那么多的空间。
如果一个表的元素个数与问题规模线性相关，建立它的空间付出至少为 O(n) （如果元素也是新创建的，还需考虑元素本身的存储开销）。
需要注意两点：
1）Python 的各种组合数据对象都没有预设的最大元素个数。在实际使用中，这些结构能根据元素个数的增长自动扩充存储空间。
从空间占用的角度看，其实际开销在存续期间可能变大，但通常不会自动缩小（即使后来元素变得很少了）。
2）还应该注意 Python 自动存储管理系统的影响。举个例子：如果在程序里建立了一个表，此后一直将其作为某个全局变量的值，
这个对象就会始终存在并占用存储空间。如果将其作为某个函数里局部变量的值，或者虽然作为全局变量的值，但后来通过
赋值将其抛弃，这个表对象就可以被回收。
3. Python 程序的时间复杂度实例
一个简单的例子。假设需要把得到的一系列数据存入一个表，其中得到一个数据是 O(l) 常量时间操作。代码如下：
data = [] whille 还有数据: x = 下一数据 data.insert(0,x) #把所有数据加在表的前面 或者写为： data = [] while 还有数据: x = 下一数据 data.insert(len(data),x) #新数据加在最后，或写append(x)
前一程序段需要 O(n) 的时间才能完成工作，而后一个程序段只需要 O(n) 时间。造成这种情况与 list 的实现方式有关。
另一个例子，建立一个表，其中包含从 0 到 10000 X n - 1 的整数值：
# 先编写一个计算时间的装饰器 import time def timer(test): def inner(*args): start = time.time() test(*args) end = time.time() - start print(end) return inner @timer def test1(n): lst = [] for i in range(n*10000): lst = lst + [i] return lst test1(5) # 3.522050380706787 @timer def test2(n): lst = [] for i in range(n*10000): lst.append(i) return lst test2(5) # 0.004010200500488281 @timer def test3(n): return [i for i in range(n*10000)] test3(5) # 0.0020058155059814453 @timer def test4(n): return list(range(n*10000)) test4(5) # 0.001033782958984375
测试环境为小米 pro 15.6 笔记本【i5处理器】。
试着尝试变化 n 值查看不同函数的增长趋势。
4. 程序实现和效率陷阱
设计一个算法，通过对它的分析可能得到抽象算法的时间与空间复杂度。
进而，采用某个变成语言可以做出该算法的实现。
那么问题来了，算法的实现（程序）的时间开销与原算法的时间复杂度之间有什么关系？
理想情况是：
作为算法的实现，相应程序的时间开销增加趋势应该达到原算法的时间复杂度。但是，如果实现做得不好，其实现程序也可能比这差。
前一话题就有这样的例子，例如函数 test1 ：最常见的错误做法就是毫无必要地构造一些可能很大的复杂结构。
例如在递归定义的函数里的递归调用中构造复杂的结构（如 list 等），而后只使用其中的个别元素。
从局部看，这样做使得常量时间的操作变成了线性时间操作。
但从递归算法的全局看，这种做法经常会使多项式时间算法变成指数时间算法。
也就是说，把原来有用的算法变成了基本无用的算法。