Re: [leafnode-list] 2.0b8_ma3 leafnode very slow

[Stefan Wiens <s.wi@xxxxxxx>]

Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> Stefan Wiens <s.wi@xxxxxxx> writes:
>
>> > Well, I looked again, after my initial reply, and found that on my
>> > machine, leafnode was operating in line-buffered mode, for whatever
>> > reason (it did not request that). 
>> 
>> Does it indeed see isatty(1)!=0?
>
> I didn't check, leafnode itself does not reference isatty().

Libc asks isatty() to find the appropriate buffering mode.
When connected via inetd(8), it chooses full buffering (4096 chars).
Maybe some inetd replacement makes stdout look like a tty?

>> Another possible reason for slow XOVER response:
>> There is a significant overhead when executing findxover() with
>> debug>0. There is an IMHO unnecessary check for correct ordering,
>> which might better be done when parsing the .overview file, making
>> qsort() unnecessary in most cases.
>
> qsort should not be the bottleneck.

But in most cases it's completely useless. When parsing .overview, one
could at no cost check the lines for ascending order and skip
sorting. Besides that, when adding new lines, some kind of insertion
sort is more efficient than qsort(). I am currently testing a separate
program for updating .overview files (after fetchnews). It takes the
same time as fixxover(), but with only 5% of its memory usage.

The same considerations apply for active information. Because
groupinfo is already sorted (normally), qsort() is overkill.
With 20,000 groups, qsort() needs more than 200,000 strcmp() calls
where 20,000 would be sufficient.

Stefan


-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list