Re: sometimes match or gmatch are very slow under luajit (compared to raw lua)
- From: Ronan Collobert <ronan@xxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 19 Sep 2012 15:04:01 +0200
Dear Mike and Jason,
Thanks for your replies.
> Actually, you can easily come up with an example where Lua 5.1
> would hit the same problem, since it uses a (different) partial
> hash, too. There are some postings on the Lua mailing list that
> show examples for the weaknesses of the various partial hashes.
I "complained" because a x10 or x20 slowdown makes it just unusable -- I do not
know the worst case performance for various existing hashes, so I cannot help.
However, reading the code of the new hash, I am a bit surprised it relies only
on 4 integers taken in the string (whatever the string size is).
if (len >= 4) { /* Caveat: unaligned access! */
a = lj_getu32(str);
h ^= lj_getu32(str+len-4);
b = lj_getu32(str+(len>>1)-2);
h ^= b; h -= lj_rol(b, 14);
b += lj_getu32(str+(len>>2)-1);
}
In any case I understand choosing a partial hash function which is fast in
general, and not-too-slow for worst cases is a tough issue.
> IMHO it's too late in the LuaJIT 2.0 release cycle to change that.
> But I'll have to tackle this problem in LuaJIT 2.1, anyway (since
> everything about the internal object layout is going to change).
Well, I will wait for LuaJIT 2.1, then...
Thanks for the great work, LuaJIT is cool.
Cheers
Ronan
Other related posts:
