Article View: demon.ip.developers
Article #64Re: Newshistory checking
From: Terrance Richard Boyes
Date: Wed, 14 Jul 1999 00:00
Date: Wed, 14 Jul 1999 00:00
58 lines
3643 bytes
3643 bytes
stefan the exiled <smd@hopf.demon.co.uk> wrote: [snip] > I can tell you the way *I* did it in C, which is probably far from the > best way... > Essentially just set up an ordered list and insert message-id's in it > as they come out of NEWNEWS or XHDR. You could experiment with various > ways of quickly finding the right place to insert (I don't think I > bothered with much more than a binary chop) and if it's already there > drop it. I considered something like that, but binary searches don't scale very well; especially if there are also a lot of inserts to be done, which there certainly would be at least when reading the history to start with. [snip] > There's also the various database libraries that I guess would work > for this purpose. Yeah, I first looked at slurp to see how it worked, they cheated and just use whichever fetch() you've got the lib for ;) > Terrance> NB a pointer to some source what I want will do just as > Terrance> well as a detailed answer ;) > Presumably suck has to do this (at least it claims to explicitly > dedupe last time I used it). Probably worth a look anyway. Just done so and suck uses both of the above. You can compile in either use whichever DB-lib you've got available or it's got some code to do the binary-tree thing otherwise. Though there's also an intriguing looking reference to INN2 and HashMessageID. Hashing is the other way I thought of doing it, though there's always that balance between memory and speed using a hash. Though thinking about it, a quick read through the file to get number of lines, it should be possible to get a good balance. Allowing a few collisions can cut down memory usage a lot, and would certainly be much faster than using btree. The other thing I was considering is that unless you make a habit of setting the newsstamp back a long way then reading the newshistory file backwards into the hash could give some performance improvement when you do actually find a duplicate. *Tez* off to have a look through the INN src now, and wondering where he left that book about optimal hashing sol'ns :) PS aaargh, and INN implements it's hashing by calling on MD5 lib functions.... -- <URL:http://www.pierrot.co.uk/> Team AMIGA Gravity is a myth, the Earth sucks.
Technical Details
Message-ID:
<19990714.001917.0AA80202.Q3aa@pierrot.co.uk>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<19990713.200500.0AA80202.PEaa@pierrot.co.uk> <m3908kgtjk.meow@hopf.demon.co.uk>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10bb05,75d5f9974c0fd91a X-Google-Attributes: gid10bb05,public From: tez@pierrot.co.uk (Terrance Richard Boyes) Subject: Re: Newshistory checking Date: 1999/07/14 Message-ID: <19990714.001917.0AA80202.Q3aa@pierrot.co.uk> X-Deja-AN: 501029681 X-PGP-Fingerprint: 20 66 0F E8 85 64 9C 2C 6F 82 6F 19 6C 2F 6A 1D X-Cancel-Lock: TEZT:63a854f1df683cccf9eac6899821bbc6 ad56c8b9b75085a1404c918c1a366d04 X-PGP-Keyfile: <URL:http://www.pierrot.co.uk/pgpauth/> References: <19990713.200500.0AA80202.PEaa@pierrot.co.uk> <m3908kgtjk.meow@hopf.demon.co.uk> X-PGP-Auth: pub 512/3A14C4B9 1999/04/22 Tez Boyes <tez@pierrot.co.uk> iQBVAwUBN4vpeEXush46FMS5AQFaqAH/Vv+Y1FoN/K2w89N+QvvKdNum2C2i461U Hyado0speKM9CFr5c+pYzPS1zTZJCqdlDOIs4QHbWgrrHiZWV+NsEQ== =1U9v X-NaMLServ: $VER: v0.9b <tez@pierrot.co.uk> X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!finch-post-11.mail.demon.net!pierrot.demon.co.uk!pierrot.co.uk!tez@pierrot.co.uk X-Trace: mail2news.demon.co.uk 931978497 mail2news:2278 mail2news mail2news.demon.co.uk Organization: ECL.Net User-Agent: tin/pre-1.4-980618 (AMIGA) X-Lan-Trace: news.pierrot.lan 19990714.001917 news:Q3aa IDENT tez@ami060.pierrot.lan Newsgroups: demon.ip.developers