none

[whaley%lbl-csam at sri-unix.UUCP]

From:  (Ken Whaley [cc])whaley at lbl-csam

:re:  speed improvements for troff.

     We have two 11/70's running version 7 UNIX that are basically dedicated to
text processing.  Therefore, most of the users are either running "vi" or some
form of nroff/troff (30 users per machine is typical during a normal work day).
The turnaround on vtroff (out main troff output device is a Versatec V-80) was 
very slow, and "vi" was suffering too, because of all the n/t/roffs.  Our 
solution was to do (as I believe was suggested in an earlier reply) a queuing
system that would:
	1) Be written in C (so as not too have the old vtroff's overhead of 
		additional processes), and be faster (if not by a whole lot).
		The queueing algorithms can be easily changed (see end of note) 
	2) Queue troff INPUT, not output, so the apparent execution time 
		of "vtroff" is increased GREATLY.  This is the main idea,
		because only one troff is running at any given time.

	(The output of troff IS queued to wait for the device.)
	This system is MUCH nicer as far as working on the computer is 
concerned.  The actual time it takes for the device to spit out the document
is increased, just how long depends on the number of documents waiting to be
processed.  However, it seems that waiting a little longer for final output is a
small price to pay for a more responsive computer. If there is an interest in
more detailed performance improvements, I'll post them to the net.

			Ken Whaley	( whaley at lbl-csam )
			Computer Services department, Computation Division
			Lawrence Berkeley Laborartory

p.s. We run DITroff, but this doesn't change the concepts here.
p.p.s. One advantage to writing the queue handling programs in C (as apposed to
shell scripts) is that they are easy to modify (if written half decently).
To give an example, we just recently added a "priority" option to vtroff, with
the ability to specify rush jobs, deferred jobs, and "hold" jobs that will do 
nothing until an operator starts it up.