代码从三行变一行，耗时从两个半小时到10秒？记一次使用 process explorer 优化程序性能的实战-技术圈

缘起

因为需要分析 tfs 提交日志，并按照一定条件（比如，提交信息或者用户名）分类整理，特意写了这个小工具。在使用过程中发现，某些情况下会花费很长时间才能返回处理结果，当时稍稍做了一些优化，已经能满足当时的应用场景了。但是在处理大文件的时候依然会花费很长时间。忍了这么久了，终于有机会做一次效率优化了。

实现逻辑介绍

整体实现逻辑并不复杂，这里稍微作下介绍：

打开需要处理的日志文件（通过 -t 参数传递，如果没指定就默认打开 tfs.txt），然后按行读取，并通过 IsSplitter() 函数判断当前行是否是分割符（由很多 - 组成），如果是就继续读取相关的字段（变更集，用户，日期，注释，项等），直到遇到下一个分隔符或者文件结尾。找出一条完整的提交记录后，会根据用户指定的过滤条件进行过滤分组，把结果输出到对应的文件中。整个过程完全是在主线程中完成的，没有用到辅助线程。

这里列出两个关键的结构定义：

class ItemInfo
{
  public string status;
  public string path;
  public override string ToString()
  {
    StringBuilder sb = new StringBuilder();
    sb.AppendFormat(@"  {0} {1}{2}", status, path, Environment.NewLine);
    return sb.ToString();
  }
}

class TfsLogInfo
{
  public string changeset = "";
  public string commitUser = "";
  public string commitDate = "";
  public string commitMessage = "";
  public List<ItemInfo> itemInfoList = new List<ItemInfo>();
}

背景介绍完毕，下面可以进行优化了。

初步观察

启动 ParseTfsLog.exe，然后使用 process explorer 观察运行情况。我录制了一段视频，如下：

可以看出，ParseTfsLog.exe 在运行过程中占满了一个核心（我的 cpu 是 8 核的，ParseTfsLog.exe 的 cpu 占用率是 12.5 左右）。仔细观察每次刷新时出现在调用栈中的函数名，名为 IsSplitter 的函数基本上每次都会出现。如果每次刷新，同一个函数都出现的话，这个函数就很值得怀疑了。

但是这个函数的实现非常简单，只有三行代码，实现如下：

private static bool IsSplitter(string curLine)
{
  var splitterRegex = new Regex(@"-{100,}", RegexOptions.Compiled | RegexOptions.IgnoreCase);
  MatchCollection matches = splitterRegex.Matches(curLine);
  return (matches.Count > 0);
}

使用正则表达式判断当前字符串中是否包含 100+ 的 -，如果包含就认为当前行是分隔符。难道正则表达式很慢？不管三七二十一，使用 string.Contains 来替换正则表达式，代码如下：

private static bool IsSplitter(string curLine)
{
  return curLine.Contains("-------------------------------------------------------------------------------------------------");
}

再次编译运行，一眨眼的功夫结果就出来了。