中国DOS联盟论坛

中国DOS联盟

-- 联合DOS 推动DOS 发展DOS --
联盟域名:www.cn-dos.net 论坛域名:www.cn-dos.net/forum
游客 | 登录 | 注册 | 会员 | 搜索 | 中国DOS联盟
中国DOS联盟论坛
现在时间是 2026-09-27 16:39
共 47,813 主题排行 / 349,918 发帖 / 今日 0 篇 / 48,276 会员排行
DOS批处理 & 脚本技术(批处理室) » 谈谈for循环的效率问题:
可打印版本  1,362 / 5
第1楼 bat-zw 发表于 2008-04-02 23:44
金牌会员 发帖 1,276 积分 3,105
谈谈for循环的效率问题:
  大家都知道for是批处理中最强大的命令,通过for循环和for镶嵌大循环可以完成很多

大批量的工作如:

就能在几秒中内实现把1-1000的整数输入到文本中(比你一个个写效率高了N倍)
 又如:

这段代码实现的是将1+1 1+2 .....1+9 2+1 2+2....2+9.........9+1 9+2.....9+9输入到

文本中(经过改写就可以生成九九加法表)。
  但在批处理中使用for镶嵌大循环应注意其工作效率,如:

  这是我早几天写下的一个代码,实现的是对1.txt和2.txt(行数相同)的跳行输出,就

是先输出1.txt的第一行再输出2.txt的第一行,然后依次类推进行跳行输出。这段代码虽能

完成这项任务,但出现了效率的大问题。它工作时首先读取1.txt的第一行和再将其行号也

就是1在2.txt的各行行号进行比对,如果行号相同就输出1.txt的第一行再输入2.txt的第一

行,然后又返回提取1.txt的第二行将行号也就是2在2.txt中进行比对行号,如行号相同同

上输出,以此类推一直到比对完1.txt和2.txt中所有的行号。
  如果1.txt和2.txt各有100行的话,那就是要比对100*100=10000次(for镶嵌中的次数

是以乘来计算的),本来最快的比对次数应是100+100=200次,足见效率有多低。
  那么怎么来解效率低的问题,这就是我要下面要讲的了:
  如果在for循环中加入判断并使用call调用语句的话,将会大大提高循环的效率,如上

面那段代码可改写为:

  这段代码由于先前设置了数值n和v的递加,第一次call调用时n为0v为1(第二次n为1v为2),先利用skip=%n%命令逐次逐行忽略对b.txt行号的比较,同时再加入if命令对行号进行比对(注意这时首行在逐次下推),一旦发现了等于v的行号(其实就是经过skip命令忽略后的首行行号)就显示输出并返回第一个for循环(中间还有个变量替换),如此也就是每次只对b.txt的一行进行比对。
虽然看上去代码要复杂了,但效率提到了最高,降到最少的比对次数200次,所以我们在使用for镶嵌大循环时一定要注意效率的问题,在达到目的情况下力求最高的循环效率!
  大家还要注意在for循环中切不可滥用findstr可多用if,经jvive兄弟的测试100000次if 否定判断用时1.63秒, 执行效率61349次/秒,而findstr .* 一个10行的文本100次 用时3.55秒, 执行效率28.169次/秒,同时本人对jvive兄弟这种认真研究的精神深表钦佩。
  因此,再次将以上代码提效修改如下:

如此才算得上是真正的高效的代码。

[ Last edited by zw19750516 on 2008-4-3 at 12:20 PM ]
第2楼 zh159 发表于 2008-04-03 00:24
金牌会员 发帖 1,467 积分 3,687
能不用findstr的地方最好不要用
第3楼 bat-zw 发表于 2008-04-03 00:28
金牌会员 发帖 1,276 积分 3,105
Originally posted by zh159 at 2008-4-3 00:24:
能不用findstr的地方最好不要用

为什么
第4楼 zh159 发表于 2008-04-03 00:38
金牌会员 发帖 1,467 积分 3,687
findstr先要读取完文件再传输给for,比for直接读取文件需要的时间稍长
测试150行文件:

需时
23:23:50.00
23:23:50.37



需时
23:24:10.00
23:24:10.01
第5楼 bat-zw 发表于 2008-04-03 00:46
金牌会员 发帖 1,276 积分 3,105
明白了,谢谢:
又学了新东西,真是学海无涯啊!
第6楼 xtanbmy 发表于 2008-04-07 19:42
初级用户 发帖 31 积分 47
很好的,学习了。
[ 联系联盟系统管理团队 - 中国DOS联盟 - 标准版 ]
Sponsored by ifanr Inc | © 2001–2023