编写高性能parse_cache()函数 （for extmail）

目前的extmail版本中，maildir的索引解析函数parse_cache()是使用正则表达式来完成的。

具体代码如下：

CODE:

sub _parse_cache {
  my $s = $_[0];
  my %info = ();
  my @a = split(/\n/, $s);
  foreach(@a) {
      /^([^=]+)=(.*)/;
      $info{$1}=$2;
  }  
  \%info;
}核心操作就是/^([^=]+)=(.*)/; 这一句。今天换了一个思路，使用perl的内建系统函数index
和substr来替换这个操作，测试一下看哪个更快。具体代码：

CODE:

sub _parse_cache {
  my $s = $_[0];
  my %info = ();
  foreach (split(/\n/, $s)) {
      my $tk = index($_, '=');
      my $len = length $_;
      $info{substr($_, -$len, $tk)} = substr($_, $tk+1);
  }
  \%info;
}核心代码就是：
my $tk = index($_, '=');
my $len = length $_;
$info{substr($_, -$len, $tk)} = substr($_, $tk+1);

这一部分。主要思路就是用index来寻找=号，找到后返回字节数，然后用substr来
获得key和value两部分。这样已经有一点c语言的味道了。在c语言里也是通过类似的
办法来切分key=value这样形式的串。

那到底哪个性能高呢？通过简单的benchmark，反复呼叫这2个不同实现的函数10万次。
执行4次平均结果：


parse_sys(): 2 wall clock (2.45CPU)
parse_reg(): 4 wall clock (3.62CPU)


第一行是采用index/substr系统函数的实现结果，第二行是用正则表达式的结果。可见用系统函数
来实现的话效率提升了30%左右。快了1秒多。

但实际意义不是很大。因为在常规的处理中，每次建立索引所需要处理的邮件数都是几百，几千，
少数用户是上万（我的postfix邮件列表目录有近9万封邮件，所以这个时间就很可观了）。所以几乎
不会感觉到有任何差异。

作为开发人员，在保证稳定可靠的前提下，应尽量追求高效能，不仅仅是代码，也还有算法等。

发这个帖子无非是抛砖引玉，希望各位有兴趣写perl的哥们充分挖掘perl的潜力：）

转自： http://www.extmail.org/forum/read.php?tid=1107&fpage=2