Thursday, May 30, 2024
Profile results are as expected as the Spanish Inquisition
I'm not upset at rewriting the code that handles the network buffering as it needed work, but I'm still seeing a disporportionate amount of CPU time accumluate on the supposedly simpler protocol gopher. The most popular requests of both my gopher server and Gemini server are entries from my blog, so I take a look at the code that handles such requests for both servers. Yes, the gohper server has a bit more code dealing with links than the Gemini server (because gopher URLs are almost, but not entirely, like http URLs—and the small differences are annoying), but I'm not seeing anything that stands out. Yes, the code is not quite twice as much, but the CPU utilization is more than three times as much (as of writing this).
I have no other choice at this point and I constantly relearn this lession over and over again: if I'm looking into a performance issue, profile the code under question! Profile profile profile!
The code is in Lua and as it happens, I've profiled Lua code before. First, I want to answer this question: how much code does it take to serve a request? And I figure measuring the lines of code run is a good answer to that. I can get a baseline from that. And the code to answer that is a very easy four line change to each server:
local function main(iostream)
local count = 0
debug.sethook(function() count = count + 1 end,'line')
-- The rest of the main code
debug.sethook()
syslog('notice',"count=%d",count)
end
I fire up the servers locally, make a decently sized request to each, and I get my results:
| gopher | 457035 |
| gemini | 22661 |
WHAT THE LITERAL XXXX‽
[Well, there's your problem! —Editor] [Just … gaaaaaaah! —Sean]
I'm constantly surprised at the results of profiling—it's almost never what I think the problem is. And here, it's clear that I messed up pretty bad somewhere in the gopher code.
Now off to more profiling to see where it all goes pear shaped.
