Bash脚本执行程序计时结果异常偏高问题排查

我开发了一款用于测试不同数据集与配置的程序，并编写Bash脚本批量执行所有测试用例。

程序计时代码 #

start = omp_get_wtime()
function()
end = omp_get_wtime() 
print(end-start) 

Bash脚本代码 #

for a in "${first_option[@]}"
do 
  for b in "${second_option[@]}"
  do 
    for c in "${third_option[@]}"
    do
       printf("$a $b $c\n")
       ./exe $a $b $c >> logs.out 
    done 
  done
done 

异常现象 #

手动执行相同配置时，程序计时结果在0.05秒到10秒间波动；但通过脚本执行时，原本耗时不足1秒的配置，计时结果均在0.999秒到1.102秒左右，无法得到更低的计时值。

核心原因分析 #

• 系统调度时间片的精度限制
  omp_get_wtime()的计时精度受系统时钟粒度影响，多数Linux系统默认调度时间片约为1ms。当程序实际运行时间远小于这个时间片时，计时器会向上取整到最近的时间片单位。脚本批量执行时，进程处于批量调度队列，调度延迟更高，导致短耗时测试用例被"凑整"到1秒左右区间；手动执行时进程可能获得更优调度优先级，能捕捉到真实短耗时。

• 频繁进程启动的额外开销
  脚本循环中每次执行./exe都需要创建新进程、加载可执行文件、初始化运行环境，这些操作本身需要数百毫秒到1秒的时间。对于实际运行时间不足1秒的测试用例，进程启动开销会完全掩盖程序真实运行时间，导致计时结果集中在启动开销区间内；手动执行时单次启动开销占比极低，能体现程序真实耗时。

• 输出重定向的缓冲延迟
  脚本中使用>> logs.out写入文件时，系统会启用块缓冲机制（默认缓冲区大小通常为4KB或8KB）。程序结束前需要等待缓冲区刷新完成，这部分额外时间会被omp_get_wtime()计入总计时；手动执行时输出到终端，系统使用行缓冲或无缓冲，额外等待时间可忽略。

解决方案建议 #

• 精准包裹核心计时逻辑
  确保omp_get_wtime()仅包裹function()中的核心计算代码，排除进程初始化、IO操作、参数解析等非核心步骤的时间。

• 避免频繁进程创建
  修改程序，将多配置测试逻辑整合到程序内部循环，一次性加载所有配置并执行，减少进程启动开销；或使用系统time命令在脚本中单独计时，分离进程启动开销与程序实际运行时间：

  /usr/bin/time -f "%e" ./exe $a $b $c >> logs.out 2>&1
  

• 禁用输出缓冲
  在脚本中使用stdbuf命令禁用输出缓冲，避免缓冲刷新延迟影响计时：

  stdbuf -o0 ./exe $a $b $c >> logs.out
  

• 提升进程调度优先级
  使用nice命令提升测试进程的调度优先级，减少调度延迟：

  nice -n -10 ./exe $a $b $c >> logs.out
  

内容的提问来源于stack exchange，提问作者Daniel Bar