我正在对程序进行一些评估测量,以测试执行时间以及检查原始系统执行的跟踪器如何影响原始系统的性能。跟踪程序不干扰系统,它们之间除了接收跟踪消息外不进行任何通信。
到目前为止,我得到的结果是953.14
未打开跟踪的程序的平均937
微秒与打开跟踪的微秒相比。时间是使用statistics(wall_clock)
函数计算的。
我的想法是,由于我有一个来自跟踪器的额外进程,并且跟踪机制需要它们自己的处理能力,因此它会减慢系统速度而不是加快系统速度。有什么已知的原因会发生这种情况吗?
我正在对程序进行一些评估测量,以测试执行时间以及检查原始系统执行的跟踪器如何影响原始系统的性能。跟踪程序不干扰系统,它们之间除了接收跟踪消息外不进行任何通信。
到目前为止,我得到的结果是953.14
未打开跟踪的程序的平均937
微秒与打开跟踪的微秒相比。时间是使用statistics(wall_clock)
函数计算的。
我的想法是,由于我有一个来自跟踪器的额外进程,并且跟踪机制需要它们自己的处理能力,因此它会减慢系统速度而不是加快系统速度。有什么已知的原因会发生这种情况吗?
您是否运行过一次或多次测量?当您使用 wall_clock 时,您将在此测量中包括对环境的潜在扰动,等待消息...,并且您没有评估 CPU 时间。下面的示例显示了它:
1> F = fun() -> receive _ -> ok after 5000 -> timout end end.
#Fun<erl_eval.20.111823515>
2> F().
timout
3> statistics(wall_clock),F(),statistics(wall_clock).
{965829,5016}
4>
函数 F 显然不需要 5 秒的 CPU 时间,而只是等待 5 秒。
这意味着您应该多次测量,一般不要使用第一次执行时间,其中可能包括加载模块代码所需的时间,并注意环境 - 同一台机器上运行的其他进程是什么,以及确保测量的时间不是等待状态的结果。
如果您使用 runtime 而不是 wall_clock,您应该会看到所需的 CPU 时间,因此在跟踪代码时会增加时间。请注意,这种时间的增加可能会被多核的使用所掩盖。