lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Jul 15, 2013 at 1:25 PM, Andrew Wilson <> wrote:
These benchmarks assume naive programmers for the languages, making them useless. 
They are useless for advanced Lua programmers; they're actually quite representative for novice Lua programmers, and somewhere in between for intermediate :) Granted, use of "local" is so simple, and well documented (wiki, gem) that there is little excuse not to use it. But only advanced Lua users have time/interest to learn such intricacies as the idiom gstr= table.concat({gstr}, str), which is an optimization at the expense of clarity. 

Actually I couldn't understand that line and sure enough, it is not equivalent to gstr=gstr..str. The intended _expression_ was likely table.concat({gstr, str}), showing again how optimization has a price (clarity, which in this case led to a typo which still compiled fine). 

So I ran some tests on stock lua 5.1 running in a virtual machine. It shows that the table.concat({gstr, str}) is in fact slower. This is (surely, but I'm no expert) because that algorithm creates a new table every time through the loop, which is if I'm not mistaken the second optimization discussed by Roberto in his gem article. So I moved the table creation out of the loop: 

local tt={gstr,str}
while i < imax+1000 do
        tt[1]=gstr; gstr=table.concat(tt) -- was gstr=gstr..str

These are the timings that I obtained, I hope the formatting doesn't get clobbered: 

str.length |
           |    A       B        C
256kb      |  48sec   56sec    47sec 
512kb      | 194sec   225sec   189sec
768kb      | 451sec   473sec   436sec

A: using "gstr=gstr..str"
B: using "table.concat({gstr, str})"
C: using "tt[1]=gstr; table.concat(tt)" (and tt={gstr,str} before the loop)

A good example of how that optimization seemed clever but is probably a bad idea: A) a hurried implementation of the table.concat trick required unclear code, leading to a typo, and even once fixed, was in fact 15% slower than the original technique; B) even once "properly" applied, the trick provided a 2% improvement only, clearly not worth the significant decrease in maintainability.