PyCharm内置Profiler可直接查看函数级耗时，基于cProfile自动捕获调用链的CPU时间、调用次数及子函数开销，启动方式为右键选择Profile；Own time表示函数自身执行时间，排查瓶颈优先关注其占比高的函数。
PyCharm内置Profiler能直接看到函数级耗时
PyCharm自带的Profiler比手写time更可靠，它不依赖你插桩位置，能自动捕获整个调用链的CPU时间、调用次数和子函数开销。启动方式很简单：右键运行文件 → 选择Profile 'xxx.py'（不是“Run”或“Debug”），几秒后就会弹出火焰图+表格视图。
注意几个关键点：
- 它默认使用
cProfile后端，对纯Python代码准确；C扩展（如NumPy底层）耗时可能被低估 - 结果里
Own time是该函数自身执行时间（不含子调用），Total time包含所有下级调用，排查瓶颈优先看Own time占比高的函数 - 如果程序含多线程，Profiler默认只追踪主线程；想分析子线程，得手动加
threading.setprofile()，但会显著拖慢运行 - 输出列表默认按
Total time降序，但点击列头可切换排序，比如按Calls找高频小函数
time.perf_counter()适合测某一段逻辑的精确耗时
当你要对比两个算法、验证某个IO操作延迟，或者Profiler太重不想开，就用time.perf_counter()——它是Python 3.3+推荐的高精度计时器，不受系统时间调整影响，且分辨率远高于time.time()。
典型写法：
import time
start = time.perf_counter()
# 你想测的代码块，比如 model.fit() 或 requests.get()
result = some_heavy_function()
end = time.perf_counter()
print(f"耗时: {end - start:.4f}s")容易踩的坑：
- 别用
time.clock()——它在Python 3.8已被移除，3.3起就警告弃用 - 单次测量误差大，尤其短于1ms的操作；需循环多次取平均，或用
timeit模块的repeat()方法 - 如果测的是GPU计算（如PyTorch forward），
perf_counter测的是主机侧发起时间，实际GPU kernel执行时间得用torch.cuda.Event或Nsight工具
命令行time python script.py给出三类系统级耗时
在PyCharm终端或系统Shell里直接跑time python xxx.py，输出的real/user/sys三值，比Python层计时更能反映真实资源占用。
PyCharm 2026.2
下载
PyCharm 2026.2是 JetBrains PyCharm 的指定版本安装包，下载地址指向官方 Windows 安装包直链，可用于旧项目兼容、版本回退和环境测试。
含义很实在：
-
real：钟表时间，从进程fork到exit的总耗时，含sleep、IO等待、调度延迟 -
user：CPU在用户态代码（你的Python逻辑）上花的时间，不含内核调用 -
sys：CPU在内核态服务你的进程所花时间，比如read()、write()、内存分配
举个例子：如果real远大于user + sys，说明程序大部分时间在等磁盘读写或网络响应；如果user接近real，基本是纯CPU密集型任务。
line_profiler能定位到哪一行代码最拖慢
当你知道哪个函数慢，但不确定是里面哪一行惹的祸，line_profiler就是答案。它需要两步：先用@profile装饰目标函数，再用kernprof -l -v script.py运行。
关键细节：
-
@profile不是标准库函数，运行时由kernprof动态注入，所以代码里不import也能用，但PyCharm不会语法高亮它 - 输出里
% Time列直接标出每行占函数总耗时的百分比，>10%的行值得优先优化 - 对列表推导式、生成器表达式这类单行多操作，它会把整行算作一个单元，无法拆解内部迭代——这时得手动拆成for循环再测
- 它会显著降低运行速度（通常2–5倍），只应在调试阶段启用，别留在生产代码里
真正难搞的从来不是“怎么测”，而是测完发现numpy.dot占了90%时间——这时候你得接受：优化边界往往在C层，Python侧能做的有限。
