[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why is READ-CHAR so blindingly slow?
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
;;; -*- Mode: LISP; Package: Common-lisp-internals; Syntax:Common-Lisp; Lowercase:T -*-
(defun read-char (&optional input-stream (eof-errorp t) eof-value recursive-p)
(let ((char (send input-stream :tyi)))
;; 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))
((not (or eof-errorp recursive-p)) eof-value)
(t (error 'end-of-file
"EOF detected by READ-CHAR in the middle of an expression in ~S"
"READ-CHAR encountered an EOF in ~S"))))))