性能的WC -l
我运行以下命令：性能的WC -l
time for i in {1..100}; do find/-name "*.service" | wc -l; done
得到了100线的结果，那么：
真正0m35.466s 用户0m15.688s SYS 0m14.552s
我然后跑以下命令：
time for i in {1..100}; do find/-name "*.service" | awk 'END{print NR}'; done
得到了100线的结果，那么：
真正0m35.036s 用户0m15.848s SYS 0m14.056s
我准确的，我已经跑了find/-name "*.service"之前，因此被缓存两个命令。我希望wc -l要更快。为什么不是？
三件事：
-
这么小的差异通常是不显著：
0m35.466s - 0m35.036s = 0m0.43s or 1.2% -
然而
wc -l比awk 'END{print NR}'更快（10倍）。% time seq 100000000 | awk 'END{print NR}' > /dev/null real 0m13.624s user 0m14.656s sys 0m1.047s % time seq 100000000 | wc -l > /dev/null real 0m1.604s user 0m2.413s sys 0m0.623s -
我的猜测是，硬盘缓存保存的
find结果，所以用wc -l后第一次运行，大部分的读取需要find是在缓存中。推测初始find与磁盘读取之间的时间差和具有高速缓存读取的第二个find将大于awk和wc之间的运行时间差。测试这个一种方法是重新启动，它会清除硬盘的缓存，然后再次运行这两个测试，但以相反的顺序，使
awk首先运行。我认为第一轮awk会比第一轮wc更慢，而第二轮wc会比第二轮awk更快。其他
几乎和'awk'一样慢'sed'。 '时间seq 100000000 | sed -n'$ ='>/dev/null'以* 12s *进入。 – agc
的已经提到，你可能会定时find，不wc或awk。尽管如此，wc和awk之间的各种口味之间可能还有一些有趣的差异。
这里是我得到的结果：
Mac OS 10.10.5 awk 0.16m lines/second
GNU awk/gawk 4.1.4 4.4m lines/second
Mac OS 10.10.5 wc 6.8m lines/second
GNU wc 8.27 11m lines/second
我没有使用find，但在替代wc -l或上一个大的文本文件'的awk“END {打印NR}”（66K线）循环。
我改变了命令的顺序，并没有发现任何偏差足以改变我报告的排名。
LC_CTYPE=C对这些中的任何一个都没有可测量的影响。
结论
不使用MAC内建的命令行工具，除了琐碎的数据。
在计数行GNU wc比GNU awk快。
我使用MacPorts GNU二进制文件。看看自制软件的二进制代码如何比较会很有趣。 （我猜他们会输。）
最初的'find'是缓存directs（inode），而不是内容。 –
'find'的结果不会被缓存。 –
@OliverCharlesworth，......好，它*略微* - dentry缓存至少意味着文件系统不需要返回到底层媒体。每次每次与文件系统交谈时，它仍然是一个新的“find”实例。 –