Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Possible TROFF speedup
Message-ID: <2707@sun.uucp>
Date: Sun, 25-Aug-85 02:04:24 EDT
Article-I.D.: sun.2707
Posted: Sun Aug 25 02:04:24 1985
Date-Received: Tue, 27-Aug-85 01:20:39 EDT
References: <658@wdl1.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 18

>      In n3.c of device independent TROFF, there is a CPP variable INCORE
> which if defined seems to turn on some I/O optimizations.  But I don't have
> the time to trace through the miserable and uncommented code in TROFF to
> figure out what is really going on.  But someone with more time might 
> find it useful to define INCORE, build TROFF, and see what happens.
> Maybe things will speed up.

If it's anything like the INCORE in the S3/S5 TROFF, it won't speed up.
INCORE is for large virtual-memory systems which aren't running UNIX.  They
do "malloc" instead of "sbrk", and use standard I/O instead of
"read"/"write".  This (especially "malloc") slows things down quite a bit.
I whipped up a VMUNIX option for TROFF once that was based on INCORE but 1)
supported compressed macro packages and 2) used "sbrk" and "read"/"write".
"time"ing that TROFF (NROFF, actually) vs. older ones and vs. 4.2BSD's NROFF
indicated that it was faster; however, the output was bursty, rather than
continuous as 4.2BSD's NROFF output was, so it seemed slower.  Go figure.

	Guy Harris