答案：Python代码执行时间测量需根据场景选择工具。使用time.perf_counter()可获得高精度、不受系统时间影响的单次计时；timeit模块通过多次重复执行并取最小值，减少外部干扰，适合小段代码性能对比；cProfile则用于分析复杂程序中各函数的调用次数、自身耗时（tottime）和累积耗时（cumtime），帮助定位性能瓶颈。优先选用time.perf_counter()替代time.time()以确保计时准确性。
Python代码执行时间的测量，核心在于选择合适的工具。从简单的计时器到复杂的性能分析器，它们各有侧重，帮助我们理解和优化代码的运行效率。选择合适的测量方法，能让你快速定位代码中的瓶颈，从而进行有针对性的优化。
解决方案
当你需要了解一段Python代码到底跑了多久时，有几种方法可以派上用场。我通常会从最简单、最直观的开始，然后根据需要深入到更专业的工具。
1. 最直接的计时：time.perf_counter()
这是我个人最常用的快速测量方法。
time.perf_counter()提供了一个高精度的、单调递增的计时器，非常适合测量短时间间隔。它不会受到系统时间调整的影响，所以比
time.time()更适合做性能测量。
立即学习“Python免费学习笔记（深入）”；
import time
def my_slow_function():
# 模拟一个耗时操作
sum(range(10**7))
start_time = time.perf_counter()
my_slow_function()
end_time = time.perf_counter()
print(f"my_slow_function 执行耗时: {end_time - start_time:.4f} 秒")2. 精准测量小段代码：timeit
模块
如果你想对比不同实现方式的性能，或者需要对一小段代码进行更严谨、更独立的性能测试，
timeit模块是你的好帮手。它会多次执行你的代码，并自动处理一些干扰因素（比如垃圾回收），给出相对稳定的结果。
import timeit
# 假设我们要比较两种创建列表的方式
# 方式一：列表推导
stmt_list_comprehension = "[i for i in range(1000)]"
# 方式二：for循环append
stmt_for_loop_append = """
my_list = []
for i in range(1000):
my_list.append(i)
"""
# setup参数用于设置执行环境，避免在计时代码中包含设置逻辑
setup_code = ""
# 运行100000次，并重复测试5次，取最好的一次结果
time_lc = timeit.timeit(stmt=stmt_list_comprehension, setup=setup_code, number=100000, repeat=5)
time_fla = timeit.timeit(stmt=stmt_for_loop_append, setup=setup_code, number=100000, repeat=5)
print(f"列表推导耗时 (最佳5次中的一次): {min(time_lc):.6f} 秒")
print(f"for循环append耗时 (最佳5次中的一次): {min(time_fla):.6f} 秒")
# 你也可以直接用timeit.Timer类
timer = timeit.Timer(stmt_list_comprehension, setup_code)
print(f"列表推导 (Timer对象): {min(timer.repeat(repeat=5, number=100000)):.6f} 秒")3. 查找性能瓶颈：cProfile
模块
当你的代码结构比较复杂，包含多个函数调用，而你又不确定是哪个函数拖慢了整体速度时，
cProfile（或其纯Python实现
profile）就派上用场了。它能帮你统计每个函数的调用次数、自身耗时以及包含子函数在内的总耗时，从而帮你定位真正的性能瓶颈。
import cProfile
import time
def func_a():
time.sleep(0.01) # 模拟IO或计算
func_b()
func_c()
def func_b():
sum(range(10**5)) # 模拟CPU密集型计算
def func_c():
time.sleep(0.005)
def main_program():
for _ in range(5):
func_a()
# 运行cProfile
cProfile.run('main_program()')
# 另一种更灵活的使用方式，可以保存结果并用pstats分析
# import pstats
# pr = cProfile.Profile()
# pr.enable()
# main_program()
# pr.disable()
# pr.dump_stats('profile_output.pstats')
#
# # 在另一个脚本或交互式环境中分析
# # p = pstats.Stats('profile_output.pstats')
# # p.sort_stats('cumulative').print_stats(10) # 按累积时间排序，打印前10行cProfile的输出结果看起来可能有点密密麻麻，但它包含了非常重要的信息，能让你一眼看出哪些函数是“时间大户”。
为什么time.perf_counter()
比time.time()
更适合代码计时？
说实话，我以前也习惯用
time.time()来测量代码执行时间，毕竟它写起来最简单。但后来我发现，当需要精确测量时，它常常会给我带来一些困惑。
time.time()返回的是系统当前的“挂钟时间”（wall-clock time），也就是我们日常看到的时钟时间。这意味着它可能会受到系统时间调整、闰秒甚至用户手动修改时间的影响。想象一下，如果你的程序在运行过程中，系统时间突然被同步了一下，或者你无意中改了时间，那你的计时结果就完全不准了。
相比之下，
time.perf_counter()提供的是一个高分辨率的、单调递增的计时器。所谓“单调递增”，就是它只会一直往前走，不会倒退，也不会因为系统时间被修改而跳变。这使得它非常适合测量时间间隔，因为它只关心起点和终点之间经过了多少个“滴答声”，而不在乎这些“滴答声”对应的是哪个具体的日期时间。对于代码性能分析来说，我们最关心的就是这段代码到底消耗了多少CPU周期或者实际运行了多久，而不是它在哪个具体时刻开始或结束的。所以，如果你想获得更可靠、更精确的计时结果，
time.perf_counter()无疑是更好的选择。当然，外部因素，比如操作系统调度、其他进程的活动，依然会影响你的代码实际获得的CPU时间，所以多次运行取平均值或者最小值（取决于你关注的是最好情况还是平均情况）总是明智的。
timeit
模块如何避免外部干扰，确保测试结果的可靠性？
我个人觉得
timeit模块是Python标准库里一个被低估的性能测试利器。它之所以能提供相对可靠的测试结果，主要有几个巧妙的设计。
首先，它在一个相对“干净”的环境中执行你的代码。当你使用
timeit.timeit()或
timeit.Timer时，你可以通过
setup参数来导入模块或定义变量。这些设置代码会在每次计时循环开始前执行一次，但不会被计入你的目标代码的执行时间。这意味着你的测试代码不会受到全局命名空间中可能存在的其他变量或函数的影响，也不会因为重复导入模块而产生额外的开销。它就像在一个临时的、隔离的沙盒里运行你的代码片段。
其次，也是最关键的，
timeit会重复执行你的代码很多次（由
number参数控制），并且整个测试过程还会重复多次（由
repeat参数控制）。然后，它会给你返回一个包含多次重复测试结果的列表。通常，我们会取这个列表中的最小值。为什么取最小值而不是平均值？因为我们假设代码的“真实”性能是最好的那个值，而任何高于这个值的测量结果都可能是由外部干扰（比如操作系统调度、垃圾回收、其他进程的短暂活动）造成的。通过多次重复运行并取最小值，
timeit能最大限度地减少这些随机、偶发的外部干扰对测试结果的影响，让你更接近代码本身的理论性能极限。
此外，
timeit还会尝试禁用垃圾回收机制（如果可能的话），以防止垃圾回收在测试过程中突然介入，从而影响单次执行的时间。这样，每次代码片段的执行都能在一个相对一致的、没有GC干扰的环境中进行。这些机制共同作用，使得
timeit成为一个非常适合对小段代码进行精确、可重复性能比较的工具。
cProfile
的输出结果中，tottime
和cumtime
分别代表什么？如何利用它们定位问题？
说实话，
cProfile的原始输出有时候让我有点头疼，因为信息量真的很大，密密麻麻的文本列表。但一旦你理解了其中的关键列，它就成了定位性能瓶颈的绝佳工具。在
cProfile的输出中，有几列是至关重要的：
-
ncalls
(number of calls)：这很简单，就是函数被调用的次数。如果一个函数被调用了上万次，即使它每次执行都很快，累积起来也可能成为问题。 -
tottime
(total time)：这是函数“自身”执行所花费的总时间，不包括它所调用的子函数的时间。换句话说，它衡量的是函数内部逻辑的执行效率。如果你看到一个函数的tottime
很高，那就意味着这个函数本身的代码逻辑效率低下，或者它内部有大量的计算/IO操作，是时候深入检查这个函数了。 -
percall
(tottime / ncalls)：这是函数每次调用的平均自身耗时。通过这个值，你可以判断函数单次执行的效率。 -
cumtime
(cumulative time)：这是函数及其所有子函数（它调用的所有函数）执行所花费的总时间。它衡量的是从函数被调用开始，到它最终返回为止，整个调用链条所花费的总时间。如果一个函数的cumtime
很高，可能不是它自身慢，而是它调用了一个或多个非常慢的子函数。 -
percall
(cumtime / ncalls)：这是函数每次调用的平均累积耗时。
如何利用它们定位问题？
我通常会这样分析：
-
首先看
cumtime
最高的函数：这通常会告诉我整个程序中最“重”的环节。一个函数的cumtime
高，意味着它或它的某个子函数是整个流程中最耗时的部分。- 如果
cumtime
高，并且它的tottime
也高，那么恭喜你，你找到了一个“自身就很慢”的函数，它的内部逻辑需要优化。 - 如果
cumtime
高，但tottime
相对较低，这意味着这个函数本身执行得很快，但它调用了其他耗时很长的子函数。这时，你需要顺着调用链条，深入到它所调用的子函数中去寻找真正的瓶颈。
- 如果
接着看
tottime
最高的函数：这能直接找出那些“干活最多”或者“效率最低”的函数。即使它的cumtime
不高（因为它可能没有调用其他函数，或者调用的子函数都很快），但如果它自身的tottime
很高，那它就是你优化的重点。注意
ncalls
：如果一个函数tottime
和cumtime
都不算特别高，但ncalls
异常高，那么即使它单次执行很快，累积起来也可能成为问题。这种情况下，你可能需要考虑减少这个函数的调用次数，或者寻找一个可以批量处理的替代方案。
举个例子，假设你有一个函数
process_data()，它调用了
read_file()和
transform_data()。
- 如果
read_file()
耗时很长（比如读取大文件），那么read_file()
的tottime
会很高，而process_data()
的cumtime
也会很高（因为它包含了read_file()
的时间），但process_data()
自身的tottime
可能很低。这时，瓶颈在read_file()
。 - 如果
transform_data()
里面有复杂的循环计算，那么transform_data()
的tottime
会很高，process_data()
的cumtime
也会很高，但process_data()
自身的tottime
可能很低。这时，瓶颈在transform_data()
。
通过这种方式，你可以像侦探一样，一步步地缩小范围，最终定位到代码中真正需要优化的地方。这比盲目地猜测或优化那些看起来“复杂”但实际不耗时的代码要有效得多。
