Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!whaley@lbl-csam From: whaley%lbl-csam@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: none Message-ID: <16284@sri-arpa.UUCP> Date: Wed, 1-Feb-84 20:16:37 EST Article-I.D.: sri-arpa.16284 Posted: Wed Feb 1 20:16:37 1984 Date-Received: Wed, 8-Feb-84 02:51:18 EST Lines: 36 From: (Ken Whaley [cc])whaley@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@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.