[文本处理] 对文本的特定字符串的提取，统计的效率问题

Iarlboko

先上代码

@echo off
::注意，cmd下文本默认都是asni的，若采用utf8之类的，中文字符会乱码。
::第二个for中抽取了2项变量，分别对应r，s（字符串1，字符串1）
title log记录文本分析工具
setlocal enabledelayedexpansion
set o="字符串初始值"
dir /b f:\工作文档\原始数据>f:\工作文档\TempFileName.txt
for /f "delims=. tokens=1" %%a in (f:\工作文档\TempFileName.txt) do (
title %%a文本分析工具
sort /+48 f:\工作文档\原始数据\%%a.txt /o f:\工作文档\原始数据\temp\%%a_sp.txt
if not exist f:\工作文档\扫描结果\%%aresult.txt echo 字符串1^;字符串2^;次数>f:\工作文档\扫描结果\%%aresult.txt
for /f "delims=:() tokens=4,6" %%r in (f:\工作文档\原始数据\temp\%%a_sp.txt) do (
   if %%r==!o!  (
     cls
     echo 文本分析工具v1.0·code by Iarlboko
     echo 工具状态：
     echo 分析中，请稍后···
   ) else  (
   set o=%%r
   find /c "%%r" f:\工作文档\原始数据\temp\%%a_sp.txt >f:\工作文档\原始数据\temp\%%a_sp_count.txt
   for /f "delims=: tokens=3" %%n in (f:\工作文档\原始数据\temp\%%a_sp_count.txt) do (
   if %%n GEQ 22 echo %%s^;%%r^;%%n>>f:\工作文档\扫描结果%%aresult.txt )
        )
) 
)
cls
echo 正在清理临时文件···
if exist f:\工作文档\原始数据\temp\%%a_sp_count.txt del /q /f f:\工作文档\原始数据\temp\%%a_sp_count.txt
if exist f:\工作文档\原始数据\temp\%%a_sp.txt del /q /f f:\工作文档\原始数据\temp\%%a_sp.txt
if exist f:\工作文档\TempFileName.txt del /q /f f:\工作文档\TempFileName.txt
echo 处理完毕！请查看目录下的结果输出文件：%%aresult.txt
echo 如有问题，请联系Iarlboko
pause
复制代码

大概的作用：
1.初期是为了实现对固定文本的特定字符串进行统计次数，并筛选符合一定次数条件的特定字符串输出到固定格式的文本
2.中期整理功能后将原计划的变量计数方式改为了利用find /c指令进行计数
3.在未整合的时候，是一次处理一个文本，同时执行多个脚本来实现对多文件处理，后发现多个脚本后cpu迅速100%负载，查看进程为多个find进行。效率还能接受。
4.整合后，利用dir指令对固定路径下的文件扫描输出文件名，并利用for循环一次提取文件名进行循环处理，达到自动处理多个文件的效果，但是这样后效率比一次执行多个脚本低了很多
5后期发现的问题有：find指令似乎在数据量较大的时候处理效率一般。批下似乎不能直接多进程执行。
6.自己临时想到的是不改变循环体结构情况下，利用call，创建临时的temp批处理，并将主批处理的代码直接输出调用，以实现多个启动。但感觉很山寨

不知，各位大侠版本有没有加快效率的方法或帮忙改良下，以实现最快的处理效果~

目前的批在处理一个10000+行的文本情况下，大概需要10-20分钟左右时间~

注：以上代码并不能复制直接使用，其中的路径和部分参数需要根据需要自己调整，比如sort指令的指定某一列排序~的 /+48就需要根据情况变下。期待高手支招解决下效率问题

[ 本帖最后由 Iarlboko 于 2009-8-4 13:44 编辑 ]

namejm

　　还请楼主以附件形式上传部分原始数据。如果原始数据涉及隐私，可做字符串替换处理；如果附件过大，请提供下载链接。只有结合原始数据才有可能保证代码的质量。

qqjue

10000多行的还用批处理处理？这个用NOTEPAD打开都要停顿下吧？像这些FIND FOR吧都是DOS命令，在WINDOWS下只能运用很少的一部分系统资源。

Batcher

如果有10000个同样的文件需要处理呢？如果每分钟都需要进行同样的处理呢？

Iarlboko

额，看周末的时候能不能整理下把实例文本传上来，原文本确实有些东西不能随便发。

目前考虑了下，效率问题是由于循环内嵌套了较多变量传递和外部命令的原因，主要是for后接find 这种多了，造成的效率比较低下。

而且代码写的也比较麻烦，都是想的用循环嵌套来控制保障文件和必要变量都能够遍历完。其中多数文件和变量处于未知状态，所以都用for来获取保证不遗漏，但这样也额外增加了处理时长，目前没有想到有通过修改部分环节直接提升效率的方式，除了重写架构  - -

Iarlboko

to 3楼，不是打开较大文本造成的效率慢，遍历文本提取变量进行匹配，匹配后再进行find统计数量，这样的循环中嵌套过多外部命令操作导致的效率慢，我估计还和管道传送变量有关。。。具体没测试过，不做确定，只是个人的一点揣测。