以前安装的vs无法正常运行性能分析工具，自己写代码统计时间，二分法查找耗时瓶颈。 一般情况下，最大的瓶颈与数据库的操作有关，改为批量处理，就会好很多。
后来改为vs旗舰版，vs自带的性能分析工具运行还算正常。 今天查出一个瓶颈，只是一个函数regex_search，不太频繁的调用，耗时占比就非常高，利用缓存绕开重复执行后，降低了所在模块60%的时间。
最近一个项目犯了判断错误。因为低估了xml工程文件的大小，以为少量数据并不影响程序效率，所以没有对xml源数据做一个内存转换。结果项目需求持续增加，经过5年后，xml工程文件的各种操作成为了项目的瓶颈。 十几年前做较大数据量处理时（10G到100G量级），一般都会以内存映射方式读取源数据，提取需要的数据转换为易于处理的类型，转存为内存数据映射文件（方便一级一级得处理）。 总结：很小的项目可以考虑使用xml文件，例如：快速开发，运行时间也不会太长，需求也不会持续增加。复杂的项目，不可以用xml这种读写，内存处理都很慢的数据形式。一定要转换为易于处理的内存对象（字符串尽量转换为整形，浮点也尽量存为整形）。
效率存在理论极限：寄存器最快、其次是内存、高速硬盘、低速硬盘、数据库… 数据库实际并不适合要求快速访问的地方。 内存数据库不一样，sqlite内存数据库模式好像是比文件数据库模式快一个量级。。 google等公司自定义的内存+光纤网络…?
类函数尽量返回引用，而不是返回拷贝。 返回引用也有缺点，外部获得引用，会被内部变更影响。这种bug出现概率很小，靠外部使用的代码自行控制是否采用拷贝，或者引用。
字符串比较拷贝拼接等都比较耗时，如果可以采用缓存节约时间，就可以考虑用空间换时间。例如xml节点的xpath属性，一般不会变，可以考虑用缓存。
