javascript里的string.split很好用，半个月之前想给lua实现一个，最初的版本：

function split(text, pattern)
    local i = 0
    local parts = {}
    for part in string.match(text, pattern) do
      i = i + 1
      parts[i] = part
    end
    return parts, i
end

这个版本只能支持正则表达式，不支持普通字符串，不支持utf-8编码，pattern也不支持传入空字符串（将字符串以字符为单位分割成数组），最让人心碎的是性能，跟javascript比，正则表达式性能差距将进10倍，如果分割单个字符如 “/”，性能差距更是近百倍，这么巨大的差距我当时就傻眼了，难道我选择lua错了？短暂的蒙逼之后开始优化。很快我用c撸了一个split出来，单字符串的，算法就是暴力的一个一个字符比较。用了c，lua的split也支持了普通字符，同样的 split(text, ‘/’)，比正则性能提升4-5倍，但跟javascript差距还是巨大。

在巨大的差距面前，我失去了理智，决定死磕到底，我不相信自己如此低能，同样是编译代码，lua与javascript代码竟然有这么大的差距？难道传说中的v8一些代码性能超过c是真的？难道lua5.3的效率跟javascript比差距如此之大？这种纯粹函数调用，字符串分割即便用luajit我认为提升效果也是有限的。luajit提升的主要是数值计算性能，对字符串有成倍的性能提升就很好了。

接下来的c版本我用void *memchr(void *s, int c, n)代替逐个字符比较，但测试结果提升非常有限，分析原因，主要是被分割的子串太短，memchr的原理是先对内存地址进行对齐，对64系统而言就是内存地址如果不是8的倍数，前面几个内存还是逐个字符比较，直到内存地址为8的倍数，然后以64位整数读取后面的数据比较（具体实现参看strlen的源代码解析，strlen本质上是memchr的特例 http://www.cppblog.com/ant/archive/2007/10/12/32886.html ），显而易见，这种方式对长度小于8的子串是不会有提升的，子串长度超过8，且对齐良好的才有提升，也就是说至少要16个字符才勉强核算，越长性能越好。

c改进版本对长字串还是有用的，但整体效果比较下来还是有20倍以上的差距，面对这些差距，我只能将单字符分割先放一放，实现utf-8字符串的空字符串分割。下面是utf-8编码规则：

/* U-00000000 - U-0000007F: 0xxxxxxx 
 * U-00000080 - U-000007FF: 110xxxxx 10xxxxxx 
 * U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx 
 * U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 
 * U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 
 * U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 
 */

了解了编码规则，将字符提取出来就简单了，编码完成，性能测试与javascript差距为一倍，看到这个结果，虽然不满意，但是心里的石头总算落下来了，这此至少不是数量极的差距。

单字符和空字符完成，接下来搞按字符串分割，字符串分割暴力比较是最显而易见的，strstr就能干，但为了性能，为了自己心灵不再受到javascript变太性能的伤害，我要选择一个性能优秀的算法，可选的有KMP，Boyer-Moore，Sunday，鉴于自己智商不足，最终选择了Sunday，Sunday是Boyer-Moore的简化版本，相对容易实现，性能上比其他两个不算差，编码实现后性能差距在10倍左右。

把三种需求都用c实现一遍之后，我不得不承认javascript的性能是太强悍了，即便javascript用正则，lua用字符打个平手也勉强。痛定思通，我要知道为什么，知道自己怎么会这么搓的？

为了知道为什么？我们需要召唤 valgrind，最初接触valgrind是在libuv的测试代码里，我当时还不知道这东西是什么，只看到每个测试函数末尾都会加一句MAKE_VALGRIND_HAPPY();，我当时就在想，这个VALGRIND是个什么东西，为什么要让他happy，他是程序员的大爷？后来我了解到，这货果然是程序员的大爷，内存检测，性能分析，这货无所不能。

性能分析用的是valgrind的工具callgrind，用它运行debug版本的程序，可以生成函数调用性能分析，每个函数被调用了多少次，耗费性能比例都能够分析出来，更妙的是，搭配gprof2dot.py（centos安装：yum install graphviz）这个图形化工具，你还能将callgrind的分析数据生成简单易懂的图片。

用valgrind对单字符split进行分析后发现，性能主要是损失在子字符串生成上，当子字符串比较短时，小于40个字符，字符串hash占了大头，当字符串长度超过40，lua给字符串内存分配占了大头。出现这种状况的主要原因是lua默认对长度小于40的字符串重复使用，不重新分配内存生成，所有相同的字符串都指向一个内存，这个时候字符串查找比较进行hash计算是主要矛盾，而当大于40长度之后，重新生成分配内存就成了主要矛盾。经过测试，lua所作的小字符优化工作可以将性能提高一倍左右，原因是相对hash计算，生成重复的对像，消耗的内存分配，GC上的性能损失更大。经过分析，显然，性能的瓶颈并不在c，而在c将字符串给lua生成字符串，这样，死磕c代码的意义已经不大了。至此，我们可以得出一个结论，对lua而言，从c向lua传递字符串的代价是很大的，只要涉及到传递字符串，最好的情况也要承受hash带来的性能损失。结论是能不传字符串就不传，能传短的就传短的。lua如此，对于javascript是不是也是这样呢？

带着这些疑问我进入了v8的源代码，这东西的源代码我看fibjs的时候看过几眼，当时就觉得看完之后眼冒金星，完全没有头绪，这是标准的智商欠费表现，从此之后我便再也没有敢去看，这次为了一探究竟只好豁出去了。正所谓智商不足勤劳补，多看几次也许能明白，况且这次目的性很强，高精尖的编译，jit看不懂就随它去了，一个runtime函数搞定应该不成问题。

带着问题，我找到了三个关键文件：

https://github.com/nodejs/node/blob/master/deps/v8/src/js/regexp.js

https://github.com/nodejs/node/blob/master/deps/v8/src/runtime/runtime-regexp.cc

https://github.com/nodejs/node/blob/master/deps/v8/src/string-search.h

源码之下无秘密，javascript为什么那么快？这个结果我先不说。我们先来回顾下memchr，KMP，Boyer-Moore，Sunday，lua对短字符串生成优化，这些算法的本质是什么？这些算法的本质是尽量不做无谓的计算，如果可以，就不计算，再不行，尽量少计算。javascript单字符查找分割跟我的算法差不多，字符串查找分割用的是Boyer-Moore，比我高级那么一点点，utf-8字符分割大家也是差不多。难道真是v8强悍到无以复加的地步？v8jit强悍在数值时是成立的，但字符串能够跟lua5.3拉开这么大差距可能有这么大的差距么？测试结果答案是肯定的，但源代码告诉我们了一切，javascript对相同字符串分割结进行了cache，也就是说，javascript对同样的字符串分割只会进行一个计算，自然也就没有子串的生成问题和GC压力，这才是优化的真谛，不必要的计算，不计算才是最快的。

因为这个问题，死磕了半个月，找到原因后，我才意识到自己犯了个大错误，过早的优化是有害的，浪费时间，打击士气，一度我都怀疑自己的选择，lua虽然在异步编程模型上比javascript好，但如果性能差距太大的话，谁会去用呢？我担心这个问题，却被一个显而易见的道理蒙蔽了，我怎么就肯定split就是性能的关键呢，那个1毫秒都不到的差距真的那么重要么？先做一个堪用的东西出来，然后一步步完善才是正途。

文中有关代码链接等我github更新后附上。