----- Original Message -----
From: Dan Eloff
Date: 4/11/2013 2:35 PM
I agree, it's good to see LuaJIT leading with things like bitops and
the ffi and Lua following. The LuaJIT ffi and performance were the
reason I chose it in the first place, I have no interest in vanilla
Lua. It's ok as a language, but there's a lot of good languages out
there with different strengths and weaknesses (usually less to do
with their syntax and semantics and more to do with the libraries and
communities around them.) The combination of easy and fast interop
with C, plus very high speed and dynamic language is a killer feature
for me.
I'm still hoping LuaJIT can one day run my own script faster that
needs a performance boost:
Step 1: The first part of my script reads the contents of a SQLite
database into a Lua table. Performance is as follows (on a super fast
Intel Xeon E5-2690 2.9 GHz CPU):
* LuaJIT 2.0 (and 2.1): 1.757 seconds
* Lua 5.1: 0.814 seconds
Step 2: The next step scans the folders of a large file system.
* LuaJIT: 7.748 seconds
* Lua 5.1: 2.34 seconds
Step 3: Then, using the information from the file scan, thousands of
files are put into various bins:
* LuaJIT: 22.818 seconds
* Lua 5.1: 2.158 seconds
Step 4: Then those bins are sorted:
* LuaJIT: 0.282 seconds
* Lua 5.1: 0.469 seconds
Step 5: The bins are all checked against various zip files already
existing on disk. This happens primarily in a C module.:
* LuaJIT: 3.518 seconds
* Lua 5.1: 3.335 seconds
I would say that, from a performance standpoint, LuaJIT has serious
issues with string manipulation, as string manipulation is the bulk of
the process in steps 1, 2, and 3.
I want to love LuaJIT. I want to throw Lua 5.1 out the window. I
can't, though, as LuaJIT performance is actually *terrible* in
comparison to Lua 5.1. Until it matches or exceeds standard Lua
performance, LuaJIT can invent new techniques/APIs all day long, but
it won't work for some situations. :(
-Josh
