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