On Mon, Jul 15, 2013 at 1:25 PM, Andrew Wilson <agrwagrw@gmail.com> 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 i=i+1; 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 | exec.tm.sec
| 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.
