I agree that specific optimizations should be done only when necessary, but it doesn't make "preemptive" benchmarks entirely useless.
Often there is more than one way of coding something, and they're equally easy to type and read. Why not prefer the fastest one then?
I was curious what is the fastest method of iterating over vararg function arguments, so I did my own benchmark. I've run it with standalone Lua interpreter on 64-bit Linux, and I used 'time' command for getting results. This is the code:
Code: Select all
local function nop (...)
end
function recur (e, ...)
if e then
return recur(...)
end
end
local ipairs = ipairs
function iter1 (...)
for i, e in ipairs {...} do
end
end
function iter2 (...)
local t = { ... }
for i = 1, #t do
local e = t[i]
end
end
local select = select
function iter3 (...)
for i = 1, select('#', ...) do
local e = select(i, ...)
end
end
local size = 2^10
local t = {}
for i = 1, size do
t[i] = i
end
local unpack = unpack
local loops = 2^10
local f = _G[...] or nop
for i = 1, loops do
f(unpack(t))
end
My average results are (in seconds):
none (just the code that runs in all of the tests) - 0.055
recur - 5.000 (4.945)
iter1 - 0.250 (0.195)
iter2 - 0.130 (0.075)
iter3 - 0.200 (0.145)
iter3 - 5.000 (4.945)
Numbers in parentheses are the results after subtracting the time of executing the code common to all of the tests.
So, it seems that the fastest way of doing it is capturing arguments in local table and iterating over it with numeric for.
Second fastest option is using numeric for with "select" function. Second was the "ipairs" variant, and the last two, equally slow are "select" variant and recursion.
Edit: Made a horrible mistake with the "iter3" test, fixed now.
For the record, there are some tips for optimizing luajit code: http://stackoverflow.com/questions/7167 ... tion-guide
