你有没有写过一个程序，明明逻辑没问题，一跑大数据就卡半天？比如用冒泡排序处理上万条订单数据，等得泡完三杯茶还没出结果——这不光是耐心问题，而是算法效率在敲黑板了。
别只看“能不能跑”，先问“跑多快”
算法效率不是玄学，核心就两点：时间花多少（时间复杂度），内存占多大（空间复杂度）。我们平时说的 O(n²)、O(n log n)，其实就是用最坏情况下操作次数的增长趋势来“估量”它。举个实在的例子：
// Python 冒泡排序（简化版）
for i in range(len(arr)):
for j in range(len(arr) - 1 - i):
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]两层循环，数组每增一倍，比较次数差不多翻四倍——这就是典型的 O(n²)。换成归并排序，同样数据量，可能眨眼就完事。
动手测一测，别光靠背公式
理论分析重要，但实测更踏实。Python 里用 time.perf_counter() 就能掐秒表：
import time
def time_sort(func, data):
start = time.perf_counter()
func(data.copy()) # 避免原地修改影响下一次测试
end = time.perf_counter()
return end - start
# 测试不同规模
for size in [1000, 5000, 10000]:
test_data = list(range(size, 0, -1)) # 逆序，让冒泡最“努力”
print(f'{size}个元素，冒泡耗时：{time_sort(bubble_sort, test_data):.4f}s')跑几轮你会发现：1000个数可能0.03秒，10000个直接跳到3秒以上——增长曲线肉眼可见偏离线性，这时候你就该怀疑：是不是该换算法了？
小改动，大提升：实现时的几个实操坑
再好的算法，写歪了也白搭。常见掉坑点：
• 提前退出没加：冒泡里如果某轮没交换，说明已有序，直接 break；
• 递归没设边界：写快速排序忘了 pivot 等于或小于1时返回，栈直接爆掉；
• 列表切片滥用：Python 里 arr[1:] 每次都新建列表，O(n) 空间开销悄悄吃掉性能。
改法也很直白：用索引传参代替切片，加 early return，关键路径少建对象。这些不改变算法复杂度，但能让实际运行快20%~50%。
工具不是银弹，人得懂原理
有人觉得“有 profiler 就够了”，确实，cProfile 能告诉你哪行慢。但它不会告诉你“为什么这行慢”。比如你发现 sorted() 比自己写的快十倍——这不是魔法，是 CPython 底层用了 Timsort（针对真实数据做了大量优化）。理解它，下次遇到部分有序的日志数据，你就知道：不用硬套快排，直接上内置函数反而最聪明。
算法效率不是竞赛题里的标准答案，它是你每天调试、上线、查监控时，那个默默影响用户体验的隐形推手。多测一组数据，多看一行 profile 输出，比死记 O 表达式管用得多。