Re: Perl, Python, Ruby, PHP, C, C++, Lua, tcl, javascript and Java comparison

[Andrew Starks <andrew.starks@...>]

On Tue, Jul 16, 2013 at 12:22 AM, oliver <oliver.schoenborn@gmail.com> wrote:
> 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.
>
> Oliver
>
>

My first encounter with table.concat was when a looping string
concatenation was taking wall-clock time. Then it took me a second to
remember that I read that sort of thing was slow and then I've never
had a problem with it.

My point is that you're a novice or intermediate Lua programmer, right
up until the point the wrong way bites you. Then in about 5 seconds,
you're a super-smart-advanced Lua programmer that knows everything
there is to know about the immutability of strings (they are
immutable) and how to do it "the right way."

So, the benchmark is useless and says nothing about how Lua performs
in the wild. IMHO, of course.

-Andrew