Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/16/85)
Unix Technical Digest Fri, 15 Mar 85 Volume 1 : Issue 25
Today's Topics:
Unix speedups (Echoin)
[Our first direct posting!]
----------------------------------------------------------------------
Date: Wed, 13 Mar 85 21:13:17 est
From: packard!harvard!macrakis
Subject: Unix speedups (Echoin)
Screen editors (vi, emacs) seem to take an inordinate amount of time
under Unix. Yesterday, for example, vi+emacs took about 16% of the
total non-idle non-netmail CPU time on our system ({v,read,r}news took
12%; csh 8%; troff 7%). Not only do they eat a good deal of CPU, but
their realtime response is such that it doesn't take much load to induce
a delay in echoing input text of over a dozen characters. This is
unacceptable.
A Modest Proposal
Since screen editing is one of the most common tasks on the machine, I
would think it ought to be well-supported. Currently, every
screen-oriented program must be unblocked, be swapped in if it's swapped
out, be scheduled, run, and execute two system calls (read and write)
for each character typed on the terminal. That's a lot of overhead for
one character. The original Emacs at MIT ran the same way originally,
but its system usage lowered and its response improved by the addition
of a special-purpose system call, called Echoin.
Echoin reads from the tty and echos the next n printing characters. The
characters are copied into the user's buffer up to but not including the
non-printing (`break') character. Of course, if an interrupt happens in
the middle of Echoin it must not lose the input characters. Echoin is
typically called by a screen-oriented routine when text is being input
at the end of the line or in overwrite mode (on the appropriate kinds of
terminals) with n set to the number of characters to the end of the
field or the edge of the screen.
The definition of break character should be a parameter of the Echoin
call, since some programs will want to run at each punctuation mark or
space, others only at control characters. A reasonable scheme would be
one bit for each of the space, the tab, the newline, the punctuation
marks, the arithmetic operators, the brackets, and all other non-
alphanumerics; control characters are always break characters, since
they can never be echoed.
Has anyone implemented such a scheme in Unix? How hard would it be?
Other Speedup Notes
The figures I gave above imply that another source of speedup might be
improving the behavior of the most commonly used programs, starting with
the news-readers. In some sense, their response time is less important,
as it serves as negative feedback to keep their use to off hours; on the
other hand, their cpu usage is overly high. I wonder to what extent
their cost might be due to using the Unix file system as the database?
Of course, much of the slowness of Unix is due to systemic problems....
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)