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]:”

local h16 = Cmt(HEXDIG^1,function(_,position,capture)
  local n = tonumber(capture,16)
  if n < 65536 then
    return position
  end
end)

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:

local h16 = HEXDIG^-4

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] /boston/2019/08/21.1

[2] /boston/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

Gemini Mention this post

Contact the author