Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site erix.UUCP
Path: utzoo!linus!decvax!mcvax!enea!erix!per
From: per@erix.UUCP (Per Hedeland)
Newsgroups: net.news.b
Subject: Speedup kludge for vnews 'p' command (a. o.) (using dbm files)
Message-ID: <459@erix.UUCP>
Date: Mon, 28-May-84 18:07:15 EDT
Article-I.D.: erix.459
Posted: Mon May 28 18:07:15 1984
Date-Received: Fri, 1-Jun-84 07:51:38 EDT
Organization: L M Ericsson, Stockholm, Sweden
Lines: 111

As followups so frequently appear before the articles they follow up to,
I find the vnews 'p' (parent) command very useful. However, if you have
a big history file, it is painfully slow. (Our history file is six weeks
long; on the other hand, we only recieve some 25% of the total news flow.)

Using the dbm files (provided your system have them, of course) is a 
rather obvious speedup. However, the information content of these is not
kept up to date as the readable file is compacted. But since expire is the
only (?) program that compacts the file, letting expire rebuild the dbm
files every time takes care of this.

The changes below assume that you have a version of expire with the -r 
(rebuild) option. The win in the 'p' command is, on our system, typically a
reduction from ~7 seconds to ~1. The same effect is (of course) achieved for 
the "article id" command to vnews, readnews. The penalty is some 10% increased
execution time for expire (who cares?). If, by chance, the entry in the dbm
files is incorrect, the programs revert to the "old" method of linear search.

Per Hedeland
per@erix.UUCP  or  ...{decvax,philabs}!mcvax!enea!erix!per


*** funcs.old.c	Sun May 27 00:09:59 1984
--- funcs.c	Mon May 28 16:50:51 1984
***************
*** 855,860
  	char oidbuf[BUFSIZ];
  	FILE *hfp;
  	char *p;
  
  	/* Try to understand old artid's as well.  Assume .UUCP domain. */
  	if (artid[0] != '<') {

--- 855,868 -----
  	char oidbuf[BUFSIZ];
  	FILE *hfp;
  	char *p;
+ #ifdef DBM
+ 	typedef struct {
+ 		char *dptr;
+ 		int dsize;
+ 	} datum;
+ 	datum lhs, rhs;
+ 	datum fetch();
+ #endif DBM
  
  	/* Try to understand old artid's as well.  Assume .UUCP domain. */
  	if (artid[0] != '<') {
***************
*** 867,872
  	} else
  		strcpy(oidbuf, artid);
  	hfp = xfopen(ARTFILE, "r");
  	while (fgets(lbuf, BUFLEN, hfp) != NULL) {
  		p = index(lbuf, '\t');
  		if (p == NULL)

--- 875,906 -----
  	} else
  		strcpy(oidbuf, artid);
  	hfp = xfopen(ARTFILE, "r");
+ #ifdef DBM
+ 	/* Use the dbm files (hoping expire is keeping them up to date) */
+ 	dbminit(ARTFILE);
+ 	lhs.dptr = oidbuf;
+ 	lhs.dsize = strlen(oidbuf) + 1;
+ 	rhs = fetch(lhs);
+ 	if (rhs.dptr == NULL) {
+ 		fclose(hfp);
+ 		return(NULL);
+ 	}
+ 	fseek(hfp, * (long *) rhs.dptr, 0);
+ 	if (fgets(lbuf, BUFLEN, hfp) != NULL) {
+ 		p = index(lbuf, '\t');
+ 		if (p == NULL)
+ 			p = index(lbuf, '\n');
+ 		*p = 0;
+ 		if (strcmp(lbuf, artid) == 0 || strcmp(lbuf, oidbuf) == 0) {
+ 			fclose(hfp);
+ 			*p = '\t';
+ 			*(lbuf + strlen(lbuf) - 1) = 0;	/* zap the \n */
+ 			return(lbuf);
+ 		}
+ 	}
+ 	/* The dbm files weren't up to date; revert to linear search */
+ 	fseek(hfp, 0L, 0);
+ #endif DBM
  	while (fgets(lbuf, BUFLEN, hfp) != NULL) {
  		p = index(lbuf, '\t');
  		if (p == NULL)


*** expire.old.c	Thu May 24 14:02:11 1984
--- expire.c	Thu May 24 14:54:57 1984
***************
*** 416,422
  		link(NARTFILE, ARTFILE);
  		unlink(NARTFILE);
  #ifdef DBM
- 		if (rebuild)
  			reblddbm ( );
  #endif
  	}

--- 416,421 -----
  		link(NARTFILE, ARTFILE);
  		unlink(NARTFILE);
  #ifdef DBM
  			reblddbm ( );
  #endif
  	}