Why is READ-CHAR so blindingly slow?

["Robert S. Kirk" <rsk%samson.cadr.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Fri, 24 Feb 89 10:23 EST
    From: Reti@RIVERSIDE.SCRC.SYMBOLICS.COM
	Date: Thu, 23 Feb 89 07:38 PST
	From: rsk@SAMSON.cadr.dialnet.symbolics.com (Robert S. Kirk)

	I'm writing a special file parser and discovered that READ-CHAR is
	*much* slower than READ-LINE, even though it does little consing.
	Theoretically, READ-CHAR create its own buffer, so it sould be only
	slightly slower than READ-LINE due to extra function invocations.

    MANY extra function invocations, plus a lot of extra error checking.

	I thought I could be smart by creating my own buffer and filling it with
	READ-CHAR.  Oh, well!

    It seems a waste to be creating a buffer of your own when the underlying stream
    is most likely buffered anyway.  

I am assuming that the underlying stream is buffered, and that is why
READ-CHAR should be very fast since it should only have to fetch a char
from the buffer.

Creating my own static buffer conses much less than using READ-LINE,
since READ-LINE has to cons a string each time its called.

    Have you tried processing the data in the
    system's buffers by using :READ-INPUT-BUFFER and :ADVANCE-INPUT-BUFFER.  I
    think you'll find that is the most efficient way to process file data.

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?