性能分析以及优化
使用的是vs2017自带的性能分析工具。
主要分析了遇到的性能瓶颈，以及想到的优化要领，有的验证了，有的没有来得及。
首先看整体用时以及cpu占有率。
最终在我的设备上(I5-5200U 三星860EVO固态)运行时间约为27.3S。期间cpu占有率对照不变.
前0.5秒cpu占用率低，概略是因为这段时间是刚开始读取文件，cpu并没有措置惩罚惩罚任务，后来便进入一边读取一遍计算的状态，cpu占有率就上来了，概略25%，但是还是不高。
而且在这里我遇到一个十分奇怪的现象
直到代码运行结束，ReadByChar的占有率一直居高不下，占有一直接近100%，这就有点难以理解，讲原理最后cpu做的是工作应该是遍历1600多万个单词查找最大值，并且觉得应该会花许多时间，也就是说查找前十的top（）函数应该在最后的的几秒占用率极高，但是没有发明这个现象，觉得应该还是这本性能分析功效本身理解有偏差把。
我们先看看性能瓶颈：
ReadByChar是我写的字符读入，以及单词判定逻辑实现的函数，并且其挪用了许多其他函数，所以它飘红是意料之中的。
进入函数，首先占用最高的是
openbychar是一个fstream的实例东西，get（）为获取字符的要领，虽然条语句花费了许多时间，但这是必需的，措置惩罚惩罚思路就是要求必需一个一个的措置惩罚惩罚，根基没有优化余地，但是假如创建东西，而是使用c语言文件读取的要领，因为不需要创建东西挪用要领，必然是可以快的，但是最后时间没来的及，就没有改。
从这里我们也可以发明，文件读取（IO）是一个瓶颈，我其时有思考大幅度改进这个问题，不太确定多线程能否改进这个问题，因为在这个措施中应该是不措置惩罚惩罚完当前字符是不会读取下一个的，但是多线程后，可以将文件分成多份分袂措置惩罚惩罚，再综合起来，因为从代码热行看，哈希表访谒长短常快的，几乎没有耗费时间，这样最后功效整合应该也花费不了几多时间，但是无奈时间匆促，而且ddl前呈现了bug，没有来得及验证，比来有时间必然试一下。
word[sword]与wordend[sword]查找都用时较多，但这个也是没有步伐的，这部分花费查找的时间也是必需的，而且拔取hash已经是想到的最优的要领，再想优化，就得针对数据特征进行分析，变动默认的hash函数 ，让单词尽量减少斗嘴，这花费时间太多了，也不必然能比默认的hash快几多，所以就没搞。
这个处所是我之前说过的独一一处算是做出有卓越结果的优化，首先这两句是完成词组拼接，每判定告成绩要执行一次，从最后单词功效看是执行了1600多万次，我之前图简单，直接写的是sphrase=sphrase+ " ”+sword，总时间占有率高达10%，但是这样写表达式右侧会先创建一个东西储存功效，然后再赋给sphrase，对照庞大，想变快应该挪用string自带的拼接要领，我变动之后，占有率直接降到1%以下。
其余的代码在整个代码运行过程中几乎不占几多时间。
但是假如真的是追求极致的话，觉得有几个细节还是可以改削下的。
1
一些经常挪用的函数中的变量东西可以用static修饰为静态，这样就不用每次挪用时候都从头创建东西了，有这个特点的是getmax（），，getmin（）函数，这两个在输出功效文件，以及查找前十中会被多次用到，但是对付一个30s的任务，这样的优化根柢没有什么感化。
2