Profiling nnrpd

Russ Allbery rra at stanford.edu
Mon Dec 23 03:22:36 UTC 2002


Jeffrey M Vinocur <jeff at litech.org> writes:

> Ok, the thing I'm finding most surprising is FindNGByNum.  That seems
> like an awful lot of time...especially since most of the articles from
> XOVER are going to be in the same newsgroups, so even the most trivial
> of caches might help.

Yeah, there isn't any cache in FindNGByNum.  The way it works is that
tradspool.map is read into a hash from newsgroup name to number and a
binary tree of number to newsgroup name.  I'd been wondering for a while
whether a binary tree was really the best data structure.

If the group numbers in tradspool.map are at all consecutive, a binary
tree degrades really badly.  I don't know if that's the case here or not.
It does look like the way that the groups are written out tends to
randomize the order a lot.

I've thought that it would be better to just have a flat array, so that
mapping newsgroup numbers to names is an O(1) operation.  It may be a bit
more memory-intensive, though.  One of the annoying things about
tradspool.map is that the memory has to be allocated for every program
that opens tradspool, including each individual nnrpd.

But I'm not seeing anything here that makes sense to me in terms of
causing really significant slowdowns like people have been reporting.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list