On Thu, Mar 24, 2005 at 06:47:27PM +0100, Vincent Lefevre wrote: > On 2005-03-24 16:12:38 +0100, Urs Janßen wrote: > > afer compiling tin with -DDEBUG and calling it with "-D 1" it shows > > that tin doesn't feeze but is damned slow (the XHDR XREF fallback > > code doesn't look very optimal, but as it usualy shouldn't be needed > > at all that's "ok"). > > What do you mean by slow?
takes several minutes (I didn't do a timing but it was something like half an hour for that group on that server). > I did a top, and tin was taking 0% CPU time. > Or was it doing transfers with the server? tin is sending NNTP commands and receving the related answers - you should see network traffic, but it doesn't cost (much) cpu. > > if you don't like that feature you can recompile with > > --disable-xhdr-xref. on 'normal' configured servers this is no > > disadvantage, but on servers which do not have the Xref:full in > > thier overviews tin isn't able to mark crossposted articles as read > > when one of them is read. > > I don't understand. When doing a catchup, tin shouldn't mark the > crossposted versions as read since they haven't been read. This of course it should, that's what x-post are for (if you read it in one group you don't have to read it again in another group) - that's the way all newsreaders handle crossposts and that's the way tin ever handled crossposts. > is particularly important when an article is crossposted to a > low-bandwidth group and a high-bandwidth group (or a group on a > less important topic). In the latter one, I don't have the time > to read everything, so that I often do a catchup there without > checking in details first. Or there could be an option concerning > the catchup behavior. feel free top implement it (or just do it as well all do it, read the low traffic grouos before catching up the high traffic groups). urs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
