一、先说一下Shell脚本语言自身的局限性

作为解释型的脚本语言，天生就有效率上边的缺陷。尽管它调用的其他命令可能效率上是不错的。
Shell脚本程序的执行是顺序执行，而非并行执行的。这很大程度上浪费了可能能利用上的系统资源。
Shell每执行一个命令就创建一个新的进程，如果脚本编写者没有这方面意识，编写脚本不当的话，是非常浪费系统资源的。

二、我们在Shell脚本语言的局限性上尽可能的通过我们有经验的编码来提高脚本的效率。

1、比如我想做一个循环处理数据，可能是简单的处理一下数据，这样会让人比较容易就想到Shell里的循环类似这样：

我们可以使用time这个脚本来测试一下十万次循环的三次执行耗时：
real 0m2.115s
user 0m1.975s
sys 0m0.138s

real 0m2.493s
user 0m2.173s
sys 0m0.254s

real 0m2.085s
user 0m1.886s
sys 0m0.195s
平均耗时2.2s，如果你知道awk命令里的循环的话，那更好了，我们来测试一下同数据规模的循环三次执行耗时：

real 0m0.023s
user 0m0.018s
sys 0m0.005s

real 0m0.020s
user 0m0.018s
sys 0m0.002s

real 0m0.021s
user 0m0.019s
sys 0m0.003s
你都不敢想象平均时间仅0.022s，基本上纯循环的效率已经比Shell高出两位数量级了。事实上你再跑百万次的循环你会发现Shell已经比较吃力了，千万级的更是艰难。所以你应该注意你的程序尽量使用awk来做循环操作。

2、关于正则，经常写Shell的同学都明白它的重要性，但是你真的能高效使用它吗？
下边举个例子：现在我有一个1694617行的日志文件 action.log，它的内容类似：
2012_02_07 00:00:04 1977575701 183.10.69.47 login 500004 1977575701 old /***/port/***.php?…
我现在想获取//之间的port的字符串，我可以这样：
awk -F'/' ‘{print $3}' 7action.log > /dev/null
但是你不会想知道它的效率：
real 0m12.296s
user 0m12.033s
sys 0m0.262s
相信我，我不会再想看着光标闪12秒的。但是如果这样执行：
awk ‘{print $9}' 7action.log | awk -F'/' '{print $3}' > /dev/null
这句的效率三次分别是：
real 0m3.691s
user 0m5.219s
sys 0m0.630s

real 0m3.660s
user 0m5.169s
sys 0m0.618s

real 0m3.660s
user 0m5.150s
sys 0m0.612s
平均时间大概3.6秒，这前后效率大概有4倍的差距，虽然不像上一个有百倍的差距，但是也足够让4小时变成1小时了。我想你懂这个差距的。

其实这个正则实例你可以尝试推测其他的情况，因为正则每次运行都是需要启动字符串匹配的，而且默认的分隔符会较快的按字段区分出。所以我们在知道一些数据规律之后可以尝试大幅度的缩短我们将要进行复杂正则匹配的字符串，这样会根据你缩减数据规模有一个非常明显的效率提升，上边还是验证的比较简单的正则匹配情况，只有一个单字符“\”,你可以试想如果正则表达式是这样：
$7!~/\.jpg$/$7~/\.[s]?html|\.php|\.xml|\/$/($9==200||$9==304)$1!~/^103\.108|^224\.215|^127\.0|^122\.110\.5/
我想你可以想象的出一个目标匹配字符串从500个字符缩减到50个字符的时候的巨大意义！

ps：另外详细的正则优化请看这个日期之后发的一篇博文。

3、再说一下shell的重定向和管道。这个条目我不会再举例子，只是说一下我个人的理解。
周所周知，很多程序或者语言都有一个比较突出的效率瓶颈就是IO，Shell也不例外（个人这么考虑）。所以建议尽可能的少用重定向来进行输入输出这样的操作或者创建临时文件来供后续使用，当然，如果必须这么干的时候那就这么干吧，我只是讲一个尽量的过程。
我们可以用Shell提供的管道来实现命令间数据的传递。如果进行连续的对数据进行过滤性命令的时候，尽量把一次性过滤较多的命令放在前边，这个原因都懂吧？减少数据传递规模。
最后我想说的连管道也尽量的少用的，虽然管道比正常的同定向IO快几个数量级的样子，但是那也是需要消耗额外的资源的，好好设计你的代码来减少这个开销吧。比如sort | uniq 命令，完全可以使用 sort -u 来实现。

4、再说一下Shell脚本程序的顺序执行。这块的优化取决于你的系统负载是否达到了极限，如果你的系统连命令的顺序执行负载都到了一个较高的线的话，你就没有必要进行Shell脚本程序的并行改造了。下边给出一个例子，如果你要模仿这个优化，请保证你的系统还能有负载空间。比如现在有这样一个程序：
supportdatacommand1
supportdatacommand2
supportdatacommand3
supportdatacommand4
supportdatacommand5
supportdatacommand6

need13datacommand
need24datacommand
need56datacommand
大意就是有6个提供数据的命令在前边，后面有3个需要数据的命令，第一个需要数据的命令需要数据13，第二个需要24，第三个需要56。但是正常情况下Shell会顺序的执行这些命令，从supportdatacommand1,一条一条执行到need56datacommand。这样的过程你看着是不是也很蛋疼？明明可以更好的做这一块的，蛋疼的程序可以这样改造：

可以类似上边的改造。这样改造之后蛋疼之感就纾解的多了。但还是感觉不是很畅快，那好吧，我们可以再畅快一点（我是指程序。。。），可以类似这样：

这样类似这样的改造，让有前后关系的命令放在一个for循环里让他们一起执行去，这样三个for循环其实是并行执行了。然后for循环内部的命令你还可以类似改造1的那种方式改造或者内嵌改造2这个的并行for循环，都是可以的，关键看你想象力了。恩？哦，不对，关键是看这些个命令之间是一种什么样的基友关系了。有关联的放一个屋里就行了，剩下的你就不用操心了。嘿嘿~~

其实这个优化真的需要看系统负载。

5、关于对shell命令的理解。这个条目就靠经验了，因为貌似没有相关的书籍可看，如果谁知道有，请推荐给我，我会灰常感谢的啊。
比如：sed -n '45,50p' 和 sed -n '51q;45,50p' ，前者也是读取45到50行，后者也是，但是后者到51行就执行了退出sed命令，避免了后续的操作读取。如果这个目标文件的规模巨大的话，剩下的你懂的。
还有类似sed ‘s/foo/bar/g' 和sed ‘/foo/ s/foo/bar/g'
sed支持采用正则进行匹配和替换，考虑字符串替换的需求中，不防加上地址以提高速度。实例中通过增加一个判断逻辑，采用“事先匹配”代替“直接替换”，由于sed会保留前一次的正则匹配环境，不会产生冗余的正则匹配，因此后者具有更高的效率。关于sed命令的这两点优化，我也在sed命令详解里有提到。

还有类似sort 如果数字尽量用 -n选项；还有统计文件行数，如果每行的数据在占用字节数一样的情况时就可以ls查文件大小然后除以每行的数据大小的出行数，而避免直接使用wc -l这样的命令；还有find出来的数据，别直接就-exec选项了，如果数据规模小很好，但是如果你find出来上千条数据或更多，你会疯掉的，不，系统会疯掉的，因为每行数据都会产生新的进程，你可以这样find …. | xargs ….；还有…(如果你也知道类似的提效率情况请你告诉我共同进步！)

三、关于优化更好的一些选择

一个比较好的提升Shell脚本的效率方法就是…… 就是…… 就是…… 好吧，就是尽量少用Shell（别打我啊！！！）下边给出一些debian官方统计的一些在linux系统上边的各个语言的效率图，咱都以C++为比较基准（系统规格：x64 Ubuntu™ Intel® Q6600® quad-core）：
这些图的查看方法，比如第一个图java和c++的程序效率比较图，总共分三个部分，分别是time、memory、code的比较，如果是c++/java ，就是说 c++做比较的分子，java做比较的分母，如果图上的长条在哪边，说明所在的那边的程序使用的时间或者内存或者代码较多，具体多多少就看长条长了多少。每一部分有多个长条图形，每个长条图案表示针对程序处理不同方面的任务时进行的测试。比如第一幅，c++和java在该环境下大部分情况下time上是差不多的，甚至java-server还有稍微的优势，内存方面c++就有很大优势，能够使用比java少的多的内容做相同的事情，但是编码量c++就稍微多一点点。以下的图类似。

通过上边的图我看可以知道C++在时间和空间上对Python、Perl、PHP有着绝对压倒性的优势，但是相对的编码量较高。同java比只有内存使用上的优势。但是我们这篇主要是针对Shell的，但是，又是但是，debian官网没有把shell脚本纳入效率比较的统计范围啊！！！还是但是，我们知道Python、Perl、PHP都是号称对Shell在效率方面有着明显的优势，所以你如果不满意你通过以上提供的种种优化途径后的Shell脚本程序的话，那你就可以尝试换一种语言了。

但是我们往往不那么容易舍弃这么好用方便而且简单的处理数据方式，也可以有个折中的方法，你先用time测试各个Shell脚本命令的耗时，针对特别耗时，特别让人不能忍受的命令的效率使用C++程序处理，让你的Shell脚本来调用这个针对局部数据处理的C++程序，这样折中貌似还是能让人接受吧？

四、最后说一下这篇是不敢称为全面或者详解的文章，是我对这一段Shell学习和实践的一些心得，希望能有高手指点。也希望能帮到新踏入这一领域的新同学。以后有新的心得再添加吧。

感谢这篇文章的作者的博文指点。

2012-02-22 ps：循环检测后台命令是否结束的判断修改：
解决方法暂时有两个（具体没有解释，不太清楚原因）：
1、

2、 检查剩余个数的语句改成 jobs -l |grep -v “Done”|wc -l

第一个方案的解决是多执行一次jobs，可以解释成为了消除最后的Done结果，但是这种解释也是行不通的，因为循环是一直执行的，在echo里已经执行很多次jobs了，何止一次。

第二个方案是过滤掉jobs最后的输出结果Done这条语句。算是绕过问题得到了期待的结果。

个人感觉bash解释器优化掉了没有后台命令执行的jobs查询命令，如果是优化掉了那也应该有个空的返回，wc依然可以得到0的结果啊。所以这个问题找不到具体原因，如果你知道请告诉我，非常感谢。。。 这里先感谢just do shell群里的Eric 沉默的土匪 GS 三人，非常感谢你们的帮助。

这里两个方法不算好方法，只是奇怪这样为什么不行，行的又该如何解释。后来知道用wait命令就全解决了，耽误那么多时间还是用的不明智的方法。

转载请注明：三江小渡厚道喔！