* * * * *
Okay, so I wasn't really done with the profiling
Last week I was surprised [1] to find this bit of Lua code as the hot spot in
“Project: Sippy-Cup [2]:”
-----[ Lua ]-----
local h16 = Cmt(HEXDIG^1,function(_,position,capture)
local n = tonumber(capture,16)
if n < 65536 then
return position
end
end)
-----[ END OF LINE ]-----
Last night I realized that this code was stupid in this context. The code was
originally based upon the original IP (Internet Protocol) address parsing
module [3] which converted the text into a binary representation of the code.
So in that context, converting the text into a number made sense. When I made
the text-only version, I did the minimum amount of work required and thus,
left in some sub-optimal code.
But here? I'm just looking at text, expecting up to four hex digits. A string
of four hex digits will, by definition, always be less than 65,536. And LPeg
[4] has a way of specifying “up to four, but no more” of a pattern. It's
just:
-----[ Lua ]-----
local h16 = HEXDIG^-4
-----[ END OF LINE ]-----
I made that change [5] to the code, and reprofiled “Project: Sippy-Cup.” It
didn't change the results at the C level all that much (the LPEG C function
merge() is still third, as I do quite a bit of parsing so that's expected),
but the results in Lua are vastly different—it's now the code that verifies
the incoming phone numbers that's the hot spot. It doesn't surprise me very
much as we do that twice per request (one for the caller, and one for the
recipient), and it's not nearly as bad a hot spot as the above code was.
[1]
gopher://gopher.conman.org/0Phlog:2019/08/21.1
[2]
gopher://gopher.conman.org/0Phlog:2014/03/05.1
[3]
https://github.com/spc476/LPeg-Parsers/blob/e6e321995c512b9076dba452569521cb4cb90cdf/ip.lua#L51
[4]
http://www.inf.puc-rio.br/~roberto/lpeg/
[5]
https://github.com/spc476/LPeg-Parsers/blob/e6e321995c512b9076dba452569521cb4cb90cdf/ip-text.lua#L42
Email author at
[email protected]
