Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Speed improvements for troff? HELP! - (nf)
Message-ID: <1638@rlgvax.UUCP>
Date: Tue, 31-Jan-84 12:33:06 EST
Article-I.D.: rlgvax.1638
Posted: Tue Jan 31 12:33:06 1984
Date-Received: Tue, 7-Feb-84 06:05:03 EST
References: <88@cfib.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 23

If the "in-memory compile flag" you mention is the INCORE option, it may
speed things up by keeping things in memory, *but* at the expense of being
built to run on more OSs than just UNIX.  The effect of this is:

1) the "compressed macro packages" are not supported, so it takes longer to
load the macro packages;

2) "troff" will use the Standard I/O library rather than using UNIX "read"
and "write", which imposes a CPU overhead, and;

3) "troff" will use "malloc" to allocate memory rather than using UNIX "sbrk",
which will also impose a CPU overhead.

We brought the S3 "nroff" up on a VAX running 4.1c, and building it with
the INCORE option actually made it take more CPU time than the V7 "nroff"
that comes with 4.xBSD (I expected it to take less, as they seem to have
tried to optimize it).  Adding a separate VMUNIX compile option, which keeps
the temp file and environments in memory but still uses "read", "write", and
"sbrk" made it take less CPU than the V7 "nroff".  (VMUNIX also permits
compressed macro packages to be used.)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy