问问题
243 次
1 回答
12
我用来--profile
更好地了解瓶颈在哪里。生成的配置文件是一个好的开始,但当差异变得非常小时,对 CPU 使用率不是很好。然而,它非常擅长跟踪对象的分配,并且更少的对象分配至少可以意味着更少的内存流失(如果对象非常短暂,则并非总是如此)。并且对事物的跟踪--profile
也会对优化产生影响,因此海森堡的不确定性原理在这里绝对适用。
一旦我有了一段之前/之后的代码,我就可以将它作为脚本运行,也可以作为带有time
. 我有一堆方便的别名可以帮助我:
alias r='time raku -e'
alias rp='raku --profile -e'
我将其作为单独的进程执行的原因至少有几秒钟,原因是:
- 在此过程中运行多个基准测试往往会使 CPU 变热,然后 CPU 会被降速,使后面的基准测试变得更糟。
- 如果两个基准测试共享核心中的一些代码,则后面的基准测试可能会受益于该代码已被早期基准测试内联/JIT。
然后我将之前和之后的代码分别运行 3 到 5 次,并Nil
循环以找出开销。所以例如:
$ r 'my $a = "42"; Int($a) for ^100000'
real 0m0.244s
$ r 'my $a = "42"; $a.Int for ^100000'
real 0m0.178s
$ r 'my $a = "42"; Nil for ^100000'
real 0m0.154s
然后计算差值:
$ r 'say (244 - 154) / (178 - 154)'
3.75
所以它的使用速度$a.Int
比Int($a)
. 这当然可以开始另一个--profile
循环,找出原因Int($a)
会慢得多。此外,当我看到无法解释的速度差异时,我会使用 a--profile
来确定它是否真的在做我认为它正在做的事情。特别是出乎意料的常量折叠有时会让您认为您找到了最佳优化,而实际上您将代码减少到基本上什么都不做。
高温高压
于 2020-05-14T09:49:50.863 回答