Why is READ-CHAR so blindingly slow?

["David L. Andre" <DLA%jasper.scrc.symbolics.com@RELAY.CS.NET>]

    Date: Fri, 24 Feb 89 10:19 PST
    From: rsk@SAMSON.cadr.dialnet.symbolics.com (Robert S. Kirk)

    Well, I guess I forgot to state that I need to stay with pure Common
    Lisp for compatiblity with VAX Lisp and Lucid Lisp.  If this was not the
    case I would meta-. my way down into system code and hack up something
    which interacted with the internal stream buffers.  Your suggestions
    above would be considered.

    I may end up making my own version of READ-CHAR which uses Symbolics
    internal on LispMs and the real READ-CHAR on other machines.

    Is there any point in telling the system something special about the
    stream when I open it so that less checking is done?

I think that the real problem you're complaining about is that READ-CHAR used to
call ZL:TYI, which does a lot of slow zetalisp-compatible stuff.  In the
development system (7.4) this has been fixed.  See if the following patch fixes
things:

;;; -*- Mode: LISP; Package: Common-lisp-internals; Syntax:Common-Lisp; Lowercase:T -*-
(defun read-char (&optional input-stream (eof-errorp t) eof-value recursive-p)
  (default-read-stream input-stream)
  (let ((char (send input-stream :tyi)))
    (cond (char
	   ;; If inside the input editor, or reading from a non-interactive
	   ;; stream, don't echo.
	   (unless (or rubout-handler
		       (not (send input-stream :interactive)))
	     ;; Echo all characters, even control and meta characters.
	     (format input-stream "~C" char))
	   char)
	  ((not (or eof-errorp recursive-p)) eof-value)
	  (t (error 'end-of-file
		    :stream input-stream
		    :format-string
		    (if recursive-p
			"EOF detected by READ-CHAR in the middle of an expression in ~S"
			"READ-CHAR encountered an EOF in ~S"))))))