PyTorch场景下cProfile统计耗时为何与time.time()实测值存在明显偏差？

两种统计方式的测量维度从定义上就存在本质差异，不存在数值天然对齐的基础：

• cProfile属于插桩式CPU侧性能剖析工具，仅统计被追踪区间内、用户态Python函数实际占用的CPU执行耗时，所有未触发Python函数执行的阻塞等待时间，都不会被纳入统计范围。
• 代码中的.to(cpu)操作确实会触发CUDA全局同步，但这个动作的CPU侧执行逻辑非常轻量：CPU只需要把“等待GPU命令队列的所有任务执行完成、回传指定张量”的指令提交到CUDA队列，就会立刻进入阻塞状态，直到GPU端完成所有排队算子计算、把目标数据回传到CPU内存，CPU才会被唤醒继续执行后续逻辑。
• 对应观测到的数值偏差：cProfile统计到的9ms，就是CPU侧执行所有Python调度逻辑的纯耗时——包括张量跨设备传输的参数解析、网络前向的算子入队、张量统计操作的调用等等；剩下的约26ms时长，是CPU阻塞等待GPU完成计算、回传数据的空等时间，这一整段过程没有任何用户态Python代码执行，自然不会被cProfile的统计逻辑覆盖。

很多开发者会默认cProfile的统计值和墙钟时间一致，本质是混淆了两类计时的适用场景：

• time.time()计算的是代码段从启动到结束的全链路墙钟时间，覆盖所有执行、等待、阻塞的完整时长。
• cProfile仅追踪Python函数的执行耗时，覆盖不了硬件等待、内核态阻塞、异步任务同步的空白区间，尤其是在使用GPU加速框架时，由于异步入队、同步等待的固有机制，两者的数值偏差会非常明显。
  如果需要准确统计包含GPU任务的完整执行耗时，不能依赖cProfile的总统计值，需要结合CUDA事件计时的方式，把GPU端的执行时间也纳入统计范围。

内容的提问来源于stack exchange，提问作者Eric Cousineau