I don't think you should rip out optimizations just because they don't
produce a clear signal above the noise of compile time. If you do a test
of just read, and it still makes no difference, then it would be more
reasonable to rip it out. If it still makes no difference it that test,
then it is likely that some bit decay has defeated this optimization, maybe
Gray streams support or something.
I will admit however, this this particular hack was added when CPUs were
thousands of times slower than they are today, and it may be time to
reevaluate. w.r.t. MP semantics, it might be reasonable to lock the stream
in the PREPARE-FOR-FAST-READ-CHAR.
Rob

If you're using SBCL on an Alpha, or you have an Alpha and you want to
use SBCL with it, you should note that
(1) Fixes checked in yesterday make it work much more reliably on
recent (ev6 and later) machines. I've also sent them directly
to the Debian SBCL maintainer, so if you're not doing CVS and you
want it fixed asap, you might want to get the Debian version when
he's uploaded.
(2) In my sleep-deprived state early yesterday morning, I decided that
SBCL on Tru64 (formerly Digital Unix, formerly OSF/1) would be neat.
It now gets as far as the prompt in cold-init, and can evaluate
(* 2 3) so it _must_ work ...
(3) The machines in the Compaq Testdrive are around 50% faster for
SBCL builds than mine is. Shame that the only access to them is
telnet, though: emacs TRAMP is incredibly slow.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources