原方法与正则表达式方法对比性能分析

Posted 2020-12-04 cugyzc

0．前言

　　写这篇随笔的原因呢，还得感谢此次结对编程与南通大学鞠老师的合作，因时间较短开发出来的小程序在性能上并没有足够多的考虑。其实我一直以来都有一种习惯，就是对于一些细枝末节的程序，并不太愿意花时间去考虑效率。更多地时间愿意花在算法的调优上，而本次的讨论，也确实影响了我，也是促动我这次认真分析一些小地方的效率情况。

　　github地址 : https://github.com/yuan574954352/WordCountByRegular

 

1.设计实验

　　在之前的实现之中的主要逻辑如下，

 

　　其中讨论的重点是继Readline()、Split()之后，对于单词的匹配处理。因此我对于其他程序依旧不改变，只改变dealline()中的代码，采用典型的控制变量思想。

 

1.1 控制变量

【原方法】

String subString = line.substring(first, end + 1);

int lengthSub = subString.length()>4? 4:subString.length();
for (int j=0 ;j<lengthSub;j++)
{
    if(isNumber(subString.charAt(j))){
        isSubHavaNum = true;
    }
}

其中SubString是截取的单词，原方法对于单词的判断是基于单词前四个字母中是否含有数字。

【正则表达式方法】

String subString = line.substring(first, end + 1);
boolean idWord =  subString.matches(Reg);
if(idWord) {

其中Reg为正则表达式。利用matches方法判断是否继续操作。

 

2.实验测试

测试文件为一篇英文文献：Tack: Learning Towards Contextual and Ephemeral Indoor Localization With Crowdsourcing

为了尽量避免因偶然误差带来的影响，我对每个方法均使用JProfiler分析3次，得出平均值。

2.1从运算正确结果分析：经测试两种方法得出结果一样，且均为下图：

 

　　感兴趣读者可自行测试，在此不再赘述。

2.2从性能分析

原方法
	dealline运行总时间	程序运行总时间
第一次	40,371	64,310
第二次	28,669	43,391
第三次	35,067	45,114

 

 

正则表达式方法
	dealline运行总时间	程序运行总时间
第一次	54,980	68,832
第二次	49,169	63,095
第三次	35,058	60,150

 

结论一：

　　我们定义 T(dealline)/T(Main) = 行处理率.

则在原方法中：行处理率1  = 62.77 %,行处理率2  = 66.07%,行处理率3 = 77.72%

　　均行处理率 =  67%

在正则方法中： 行处理率1  = 79.87 %,行处理率2  =77.93%,行处理率3 = 58.28%

　　均行处理率 =  72%

从以上分析，我们很明显的看到，正则表达式的方案并不会比我们原来使用的方案提高效率！反而使用正则表达式程序会花费大量时间在 java.lang.String.matches 方法上。

　　结论二：

　　事实上，正则表达式方案反而会使方案降低效率，其中平均降低效率为 0.015s/1.4万字母。而这样的效率降低在现实中是完全可以接受的。

换句话说就是 你有一个 100万字母的英文文本，词频统计效率才会下降1s,而且考虑到本人计算机本身计算效率不高，这样的效率改进是没多大意义的！