rich@cfib.UUCP (01/26/84)
#N:cfib:11100006:000:1423
cfib!rich Jan 25 11:49:00 1984
We have an HP-9000 Series 500 running System III UNIX. This machine has
2.5Mb memory and 2 cpus in it. We are a company that runs
tbl | troff -ms | <postprocessor>
pipes for up to 12 hours every night (sometimes during the day) for our Xerox
8700 laser printer, producing 50 or 60 40-page documents a day. Each document
currently takes 8 to 10 minutes in the format pipe. Obviously, it would be of
great value to us if we could improve the performance of troff. We tried
compiling it (troff) with the in-memory compile flag set, but this caused our
machine to page fault like crazy and made troff run 70% SLOWER. Our working
set ratio allows the machine to expand memory fully until there is no more
available; since the test ran on an otherwise empty machine, it is hard to
believe it ran out of memory. We have contacted HP technical support in
Ft. Collins and are waiting for a response. I would guess this is an HP
problem.
Has anyone had any success with the in-memory compile flag? If so, what was the
performance improvement? Does anyone have any suggestions for us? Does anyone
know of any versions of troff that have been modified or rewritten to improve
performance? (You mean someone that actually looked at and (gasp) MODIFIED
troff code?)
Thanks in advance.
Rich Baughman
The Consumer Financial Institute (a.k.a. C.M. Leinwand Associates)
Newton, MA
617-969-9460
...decvax!cca!ima!cfib!richguy@rlgvax.UUCP (Guy Harris) (01/31/84)
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!guychris@umcp-cs.UUCP (02/01/84)
I don't know which system you're using, so this may not be any
help, but I hacked on the source code for 4.1BSD Vax [nt]roff to
try to cut down on total number of subroutine calls. Simple
benchmarks (running off the paper I was working on) showed about
a 10-15% improvement. I strongly suspect that my changes will
not work on other (System III, V) [nt]roff sources, but I could
post diff listings if there is enough interest.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaygwyn%brl-vld@sri-unix.UUCP (02/01/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> There is really not much one could do to significantly speed up troff. "Compressed" macros help somewhat, but the real problem is that troff is one of the very few compute-bound UNIX utilities. There are a few operational measures you should consider: (1) Prohibit troffing documents until they are debugged under nroff; (2) Use dynamically loaded macro packages such as -me or -mm; (3) Use compressed macros; (4) Run troff in the background in a batch queue; (5) Buy more computing power to dedicate to typesetting.
guy@rlgvax.UUCP (Guy Harris) (02/04/84)
I posted an article earlier mentioning changes to the S3 "nroff" (probably
applicable to the S5 "nroff" as well) which add a VMUNIX compile option which
works like the INCORE compile option, only it still thinks it's being built
for a UNIX system. Thus, it doesn't use standard I/O or "malloc", and supports
compressed macro packages, which make it run faster. It also includes some
bug fixes (which, among other things, make it work with the "-me" package) and
a fix so that it doesn't rely on a compiled-in notion of the current timezone
but uses "localtime" to dissect a UNIX time-since-the-epoch value.
I am posting a "diff -c" listing to "net.sources". (It is being done, in part,
for the benefit of the UNIX System Development Group at Bell Labs - hint, hint,
hint, hint, hint - after all, if System V is eventually going to get
virtual memory, it may come in handy...)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyphil%rice@sri-unix.UUCP (02/08/84)
From: William LeFebvre <phil@rice>
This quote seems to fit in rather well:
Efficiency is always a problem, and is likely to be so forever,
especially with the proliferation of preprocessors generating
ever more complicated input. Small improvements (perhaps 10
percent) can be had from artifices like better table searching.
Placing the temporary file upon which TROFF stores macro
definitions in memory is good for another 10-20 percent on
machines like the VAX that have enough memory. But no
order-of-magnitude speedup is likely without a gross revision
of the basic design.
--"A Typesetter-independent TROFF"
Brian W. Kernighan
Looks like you're stuck with "TROFF the resource hog" for a while
(unless someone cares to revise the basic design or just plain rewrite
the thing).
William LeFebvre
Department of Mathematical Sciences
Rice University
<phil@rice>