[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [Benchmark] Chain calls
- From: "Alexander Gladysh" <agladysh@...>
- Date: Tue, 25 Nov 2008 10:26:56 +0300
On Tue, Nov 25, 2008 at 7:19 AM, KHMan <keinhong@gmail.com> wrote:
> Alexander Gladysh wrote:
>>
>> On Mon, Nov 17, 2008 at 3:38 PM, Peter Cawley <lua@corsix.org> wrote:
>>>
>>> It may be worth looking at the generated Lua opcodes for these benchmarks
>>> in
>>> order to easier see the differences in what is happening in each. For
>>> example, return true v.s return nil are loadbool,return vs.
>>> loadnil,return.
>>> Then looking at the VM code for these operations, either in C or as the
>>> assembled output of the C, might make it clearer. Of course, this won't
>>> help
>>> with explaining the luajit results, as it skips the VM when JITing.
>>
>> Sorry for the late reply.
>>
>> Opcode listing (via luac -l -l) is indeed very helpful. Chaining calls
>> use less resources, since they do not require extra MOVE opcodes:
>>
>> local function chain_local()
>> local chain = chain
>> chain () () () () () () () () () () -- 10 calls
>> end
>
> [snip]
>
> Trouble is, does this pattern ever appear in normal code? I find it
> difficult to believe that calling a function that returns a function to be
> called, and so on, chained in this manner, could happen in real-world code.
Well, it does in mine. I often use this idiom for heavy concatenation
code (for one thing, you may easily replace buffering cat() with
io.write()):
local buf = {}
local function cat(s)
buf[#buf + 1] = s
return cat
end
local function test()
cat "one" "two" "four" "five"
end
function <chainstr.lua:8,10> (10 instructions, 40 bytes at 0x100eb0)
0 params, 2 slots, 1 upvalue, 0 locals, 4 constants, 0 functions
1 [9] GETUPVAL 0 0 ; cat
2 [9] LOADK 1 -1 ; "one"
3 [9] CALL 0 2 2
4 [9] LOADK 1 -2 ; "two"
5 [9] CALL 0 2 2
6 [9] LOADK 1 -3 ; "four"
7 [9] CALL 0 2 2
8 [9] LOADK 1 -4 ; "five"
9 [9] CALL 0 2 1
10 [10] RETURN 0 1
Alexander.