Wei*_*hou 4 performance sed awk
我试图了解一些与sedand相关的性能问题awk,我做了以下实验,
$ seq 100000 > test
$ yes 'NR==100001{print}' | head -n 5000 > test.awk
$ yes '100001{p;b}' | head -n 5000 > test.sed
$ time sed -nf test.sed test
real 0m3.436s
user 0m3.428s
sys 0m0.004s
$ time awk -F@ -f test.awk test
real 0m11.615s
user 0m11.582s
sys 0m0.007s
$ sed --version
sed (GNU sed) 4.5
$ awk --version
GNU Awk 4.2.1, API: 2.0 (GNU MPFR 3.1.6-p2, GNU MP 6.1.2)
Run Code Online (Sandbox Code Playgroud)
在这里,由于测试文件仅包含 100000 行,因此test.sed和test.awk中的所有命令都是无操作的。两个程序只需要将行号与地址(in sed)或NR(in awk)进行匹配就可以决定命令不需要执行,但是时间成本还是有巨大的差异。为什么会这样?是否有人安装了不同版本sed并awk在此测试中给出了不同的结果?
编辑:结果mawk(如@mosvy 所建议),original-awk(@GregA.Woods 所建议的基于 debian 的系统中“一个真正的 awk”的名称)并perl在下面给出,
$ time mawk -F@ -f test.awk test
real 0m5.934s
user 0m5.919s
sys 0m0.004s
$ time original-awk -F@ -f test.awk test
real 0m8.132s
user 0m8.128s
sys 0m0.004s
$ yes 'print if $.==100001;' | head -n 5000 > test.pl
$ time perl -n test.pl test
real 0m33.245s
user 0m33.110s
sys 0m0.019s
$ mawk -W version
mawk 1.3.4 20171017
$ perl --version
This is perl 5, version 28, subversion 1 (v5.28.1) built for x86_64-linux-thread-multi
Run Code Online (Sandbox Code Playgroud)
更换-F@与-F ''不使的情况下,可观察到的变化gawk和mawk。original-awk不支持空FS。
编辑 2
@mosvy 的测试给出了不同的结果,21s forsed和 11s for mawk,详细信息请参阅下面的评论。
awk 具有比 sed,具有更灵活的语法。因此,解析其脚本和执行它们需要更长的时间并不是没有道理的。
由于您的示例命令(大括号内的部分)从未运行,因此时间敏感部分应该是您的测试表达式。
首先看awk例子中的测试:
NR==100001
Run Code Online (Sandbox Code Playgroud)
并查看gprof(GNU awk 4.0.1) 中的效果:
% 累积自我总和 时间 秒 秒 呼叫 s/呼叫 s/呼叫名称 55.89 19.73 19.73 1 19.73 35.04 解释 8.90 22.87 3.14 500000000 0.00 0.00 cmp_scalar 8.64 25.92 3.05 1000305023 0.00 0.00 free_wstr 8.61 28.96 3.04 500105014 0.00 0.00 mk_number 6.09 31.11 2.15 500000001 0.00 0.00 cmp_nodes 4.18 32.59 1.48 500200013 0.00 0.00 未参考 3.68 33.89 1.30 500000000 0.00 0.00 评估条件 2.21 34.67 0.78 500000000 0.00 0.00 更新_NR
大约 50% 的时间花在“解释”上,这是运行解析脚本产生的操作码的顶级循环。
每次运行测试时(即 5000 行脚本 * 100000 行输入),awk必须:
update_NR)。mk_number)。cmp_nodes, cmp_scalar, eval_condition)。free_wstr, unref)其他awk实现不会有完全相同的调用流程,但它们仍然需要检索变量,自动转换,然后比较。
相比之下,在 中sed,“测试”的局限性要大得多。它只能是单个地址、地址范围或什么都没有(当命令是行上的第一件事时),并且sed可以从第一个字符判断它是地址还是命令。在这个例子中,它是
100001
Run Code Online (Sandbox Code Playgroud)
...单个数字地址。配置文件(GNU sed 4.2.2)显示
% 累积自我总和 时间 秒 秒 呼叫 s/呼叫 s/呼叫名称 52.01 2.98 2.98 100000 0.00 0.00 执行程序 44.16 5.51 2.53 1000000000 0.00 0.00 match_address_p 3.84 5.73 0.22 match_an_address_p [...] 0.00 5.73 0.00 5000 0.00 0.00 in_integer
同样,大约 50% 的时间在顶级execute_program. 在这种情况下,它在每个输入行调用一次,然后遍历解析的命令。循环以地址检查开始,但这不是您示例中的全部功能(见下文)。
输入脚本中的行号在编译时被解析 ( in_integer)。对于输入中的每个地址编号,只需执行一次,即。5000 次,并且对整体运行时间没有显着贡献。
这意味着地址检查,match_address_p只比较已经可用的整数(通过结构和指针)。
sed改进配置文件显示match_address_p调用2*5000*100000次,即。每个脚本行*输入行两次。这是因为,在幕后,GNUsed处理“启动块”命令
100001{...}
Run Code Online (Sandbox Code Playgroud)
作为块末尾的否定分支
100001!b end; ... :end
Run Code Online (Sandbox Code Playgroud)
此地址匹配在每个输入行上都成功,从而导致跳转到块 ( })的末尾。那个块端没有关联的地址,所以它是另一个成功的匹配。这就解释了为什么在execute_program.
因此,sed如果省略未使用的表达式,则该表达式会更快;b,结果是不必要的{...},只留下100001p.
% 累积自我总和 时间 秒 秒 呼叫 s/呼叫 s/呼叫名称 71.43 1.40 1.40 500000000 0.00 0.00 match_address_p 24.49 1.88 0.48 100000 0.00 0.00 执行程序 4.08 1.96 0.08 match_an_address_p
这将match_address_p调用次数减半,并且还减少了花费的大部分时间execute_program(因为地址匹配永远不会成功)。