>>3
LuaJIT and Lua/LLVM still using those god damn look-up tables in the JITed code.
The table look up certainly isn't ideal, compared to indexing into an organized location within a struct, but it isn't that bad. Strings in lua are interned into a symbol table, which means that all strings with equal contents are actually the same string, starting at the same memory address. Because of this, using strings as keys in a hash table in lua is as efficient as using pointers as keys. Also, many class-like and struct-like tables in lua don't usually have that many fields, maybe 12 or 15 at the max, unless of course there is a massive amount of inheritance going on. Any more and it wouldn't be easy for a programmer to follow the code. A typical hash table using some type of probing scheme will usually keeps it's array length around twice as much as there are objects in it, yielding structs that are around twice as large as they normally would be. This a cost, but it isn't that bad. Lua is a simple language, and typically out performs other interpreted languages. It's flaws aren't in speed. You can certainly criticize it for not having any support for threads, and having a pretty limited standard library. You can't even do a chdir without extending it with C, and there isn't built in support for real regular expressions, which is a little baffling for me since it is a scripting language and regex is usually their niche.