总结一次C++ 程序优化历程

近期用到了一位师兄写的c++程序，总体功能良好。使用不同的数据测试，发现了一个明显的缺点：大数据量下，预处理过程耗时很长。中科院的某计算集群，普通队列中的程序运行时间不能超过6个小时。而手上这套程序，大数据量下预处理就花了不止六个小时，结果当然是还没开始就被结束了。

和天河二号的工作人员联系，确认没有执行时间限制。于是开通了天河二号的账号，把程序扔上去跑。执行大数据量时，程序莫名被kill。询问技术支持，得知是内存耗尽，建议每个节点的进程数少一点。如此折腾了两次，大数据量的例子没跑通，大部分时间都费在预处理上，然后程序崩了，又要调整参数重新再来。

耗时长，最多是多花点机时，问题不大。但是没跑通的情况下每次要等五六个小时，然后才知道能否运行，测试然后反馈的过程太低效。忍无可忍，就开始进行优化吧！

第一步，找出耗时的点。原来的程序输出日志用的cout，没有附带时间，不能通过日志发现耗时的点。为了找出性能关键点，第一步是改进log，在输出中加上时间。写了一个log类，替换掉cout，程序的输出中就带上时间了：

#include "../include/log.hpp"

#include 
#include 
#include 
#include 

using namespace std;

namespace tlanyan {

 string log::datetimeformat = "%f %t";

 log::log()
 {
 }

 void log::info(const char* message) {
  cout << getcurrenttime() << " [info] " << message << endl;
 }

 void log::debug(const char* message) {
#if debug
  cout << getcurrenttime() << " [debug] " << message;
#endif;
 }

 const char* log::getcurrenttime()
 {
  //locale::global(locale("zh_cn.utf8"));
  time_t t = time(null);
  char mbstr[512];
  if (strftime(mbstr, sizeof(mbstr), log::datetimeformat.c_str(), localtime(&t))) {
   return mbstr;
  }
  
  cerr << "获取或格式化时间错误!" << endl;

  exit(1);
 }

 log::~log()
 {
 }
}

// 调用示例：
log::info("program begins...");

通过查看log，定位到了耗时长的过程。

• 第一步，目测程序源代码，找出问题所在。该段代码比较好理解，主要是进行数据初始化和打标签。程序中规中矩，都是操控内存中的数组，没有磁盘、网络、进程通信等耗时调用。审查代码中发现第一个问题：内存重分配。程序声明了vector，没有指定大小，后续代码中使用push_back对数组的每一项进行赋值。内存分配和数据拷贝的代价是很大的，这应该是一个性能点。修改代码，声明时指定数组大小。编译并运行程序，结果表明省下了30%的耗时。
• 第二步，统计代码的工作量。耗时过程的初始化数据量，大概是整个数据量的10%，就算其中内嵌了两层循环，也不应该耗时如此多。为了查看是否有额外工作量，加入了计数器。运行结果显示，该段函数的计算量不大，耗时长应该有其他的原因。
• 第三步，根据经验判断是缓存失效导致。第一反应是用valgrind查看缓存命中，但valgrind模拟运行的效率太差，几个小时后kill掉放弃了。目测程序源码，发现很多数据都是从全局内存读取，没有充分利用缓存。修改代码，使用局部变量缓存全局数据，接下来代码中的数据使用缓存数据。经过测试，效果非常明显，提升了50%的效率。
• 第四步，查找其他性能热点。经过几次小的调优测试，发现一些全局内存访问不可避免（随机访问，无法利用缓存），按照目前的方式难以继续优化。要大幅降低耗时需要重写算法，目前无法保证对算法和程序意图十分了解，遂暂时作罢。

优化前后的结果对比：中等数据规模下，耗时从8'43"降到3'25"；大数据量下，耗时从4h38'44"降到1h49'21"（注：使用自己的机器测试，cpu主频3.46ghz，比中科院和天河二号集群的cpu主频都要高，所以耗时短）。从数据看出，效果还是很明显的。

以上就是c++ 程序优化历程总结的详细内容，更多关于c++ 程序优化的资料请关注其它相关文章！