云风的 BLOG: lua 中判断字符串前缀

« lua 调试器制作注意 | 返回首页 | 《链接、装载与库》书评 »

lua 中判断字符串前缀

一个 lua 的小技巧

在写 lua debugger 的时候，我需要判断一个字符串的前缀是不是 "@" 。

有三个方案：

比较直观的是 string.sub(str,1,1) == "@"
感觉效率比较高的是 string.byte(str) == 64
或者是 string.find(str,"@") == 1

我推荐第三种。（注：在此特定运用环境下。因为用于判定 source 的文件名，大多数情况都是 @ 开头。如果结果为非，则性能较低）

第一方案 string.sub 会在生成子串的时候做一次字符串 hash ，感觉效率会略微低一些。

第二方案效率应该是最好，但是需要记住 @ 的 ascii 码 64 。如果前缀是多个字符也不适用。

云风提交于 May 26, 2009 10:40 PM | 固定链接

Comments

似乎遗漏了string.char这个函数。string.char(s,1)应该是可读性最强的

Posted by: mayao11 | (13) July 29, 2015 10:21 AM

性能对比
string.find(sb, "@") == 1 3.671
string.find(sb, "^@") ~= 1 3.735
string.byte(sa) == 64 2.14
string.char(string.byte(sb)) == "@" 4.375
string.sub(sb,1,1) == "@" 2.766
sb[1] == "@" 0.984

Posted by: SloanYi | (12) June 8, 2012 02:31 PM

要想解决不以@开头时的性能问题，可以改成这样：
string.find(str,"^@") == 1

Posted by: Atry | (11) May 29, 2009 01:39 PM

lua --- 不了解 , 一般情况下判断性能如何结合具体情况通过执行过程来评估还是不错的,我是类比的SQL的解决方案

Posted by: SunJian | (10) May 28, 2009 10:56 PM

感谢分享，我学习了，非常的好

Posted by: 桂林旅游 | (9) May 28, 2009 09:35 PM

是的，如果文件不以 @ 开头，性能会降低。

这个场合是个特别的地方，大部分字符串都是 @ 开头。

在 lua RemDebug

http://www.keplerproject.org/remdebug/

中也是这么用的。

string.sub 的成本是构造新的 string 。很难说哪个好。

在乎不在乎性能，不在于选择能做到的性能最高的方案。（比如用 C 专门写一个函数）

而在于，有几个同等方案备选时，可以决策出一个较好的。

但从性能角度看，比较而言，第 2 方案无疑是最高的。

我觉得无所谓聪明不聪明，三个方案写起来都还算自然。

Posted by: Cloud | (8) May 27, 2009 08:02 PM

第三种方案好弱啊，我记得以前的同事在Ｃ中判断一个字符串a是否起始于字符串b，用了一个看试很聪明的方法，strstr(a, b) == a。但是如果字符串a不是起始于b的时候效率极低啊，差了一个数量级。特别的是这个方法还被经常用到在分析一整个字符串的时候，效率之低简直无法想象。
其实如果这么在乎效率的话，扩展一下string，自己用Ｃ包装一个不行吗？还用这种看似很聪明的方法？

Posted by: iTana | (7) May 27, 2009 07:50 PM

这是我博克，欢迎回访
http://sites.google.com/site/wsaelel/

Posted by: 也许知道 | (6) May 27, 2009 05:16 PM

关于性能，如果相差不大的话，用最易懂的，
如果相差很大的话，用最快的

试一试还是有必要的

Posted by: 半瓶墨水 | (5) May 27, 2009 12:29 PM

第三个方案，看错了，这个方案看起来最不直观

奇怪，lua不提供单独取字符的函数吗？

Posted by: 半瓶墨水 | (4) May 27, 2009 12:27 PM

楼下，第 3 方案是精确的。

性能并不是写小程序就可以得到结论的。

如果写简单的测试，第一方案会比第三方案快。因为简单测试环境下，字符串池里几乎没有什么串， hash 的开销可以不计。对 gc 的影响也无法准确判断。（第三方案不生成对象，对 gc 无影响）