2

I am trying to make a speedtest using Lua as one of the languages and I just wanted some advice on how I could make my code a bit faster if possible. It is important that I do my own speedtest, since I am looking at very specific parameters.

The code is reading from a file which looks something like this, but the numbers are randomly generated and range from 1 zu 1 000 000. There are between 100 and 10 000 numbers in one list:

type
(123,124,364,5867,...)

type
(14224,234646,5686,...)

...

The type is meant for another language, so it can be ignored. I just put this here so you know why I am not parsing every line. This is my Lua code:

incr = 1
for line in io.lines(arg[1]) do
  incr = incr +1
  if incr % 3 == 0 then
    line:gsub('([%d]+),?',function(n)tonumber(n)end)
  end
end

Now, the code works and does exactly what I want it to do. This is not about getting it to work, this is simply about speed. I need ideas and advice to make the code work at optimal speed.

Thanks in advance for any answers.

HolgerS
  • 87
  • 7

1 Answers1

3

IMHO, this tonumber() benchmarking is rather strange. Most of CPU time would be spent on other tasks (regexp parsing, file reading, ...).

Instead of converting to number and ignoring result it would be more logical to calculate sum of all the numbers in input file: 

local gmatch, s = string.gmatch, 0

for line in io.lines(arg[1]) do
  for n in gmatch(line, '%d+') do
    s = s + n  -- converting string to number is automatic here
  end
end

print(s)
Egor Skriptunoff
  • 23,359
  • 2
  • 34
  • 64
  • Yes, this does make it a lot faster. Thanks. – HolgerS Jul 31 '13 at 19:20
  • Keep in mind that `tonumber()` can catch failed string-to-number conversions while `str+k` would cause a Lua error. – dualed Aug 01 '13 at 06:08
  • @dualed - conversion `k = k + str` would NEVER cause a Lua error if `str` was extracted by `%d+` pattern. For very long `str` it would simply return NaN (namely, `1.#INF`) without raising any Lua error. – Egor Skriptunoff Aug 01 '13 at 08:49
  • Yes, but this is just the benchmark, @HolgerS wants to use it somewhere else too, obviously. Also... Since you address this, there may be different views on this, but most of the time I would have preferred an error to `1.#inf` when I encountered it. – dualed Aug 01 '13 at 12:42
  • @dualed - as for me, treating out-of-range numbers and the infinity as usual numbers is very handy. Integer arithmetic lacks this fine feature and forces you to always think of error handling on every step. – Egor Skriptunoff Aug 01 '13 at 14:55