[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:23 EST
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?