>>107006621
>https://bugs.launchpad.net/sbcl/+bug/2129811
>A workaround might be available: depending on your OS and use case, you could do
>(setq *standard-input* (open "/dev/stdin"))
>But note that the semantics of "/dev/stdin" differ in ways that could conceivably matter between Linux and other Unices, so this is just a suggestion.
>That it's a synonym stream (to a bivalent stream) also slows it down.
>In my measurements, READ-LINE on a bivalent input stream is about 9x
>slower than on a character-only stream, and each level of composite
>stream adds another roughly 3x. [Edit: this is for reading lines with
>an average length of 70. Obviously, these numbers will vary with
>line length.]
>Additionally, and counterintuitively, READ-SEQUENCE into a string
>is slower than READ-LINE on builtin streams that have no CIN buffer
>than on character-only, input-only FD-STREAMs. [Edit: same inputs as
>I'm using to measure READ-LINE.]
>Anyhow, I've been working on this recently, and it's ready enough
>for review (just 2 commits at the moment):
>https://github.com/kreuter/sbcl/commits/read-some-chars/
>For the stream types I've covered, that approach makes READ-LINE,
>READ-SEQUENCE into a string between 3.75x and 130x faster than
>in 2.5.5 (an arbitrary baseline I had around). Bivalent UTF-8/linefeed
>streams are still 2.75x slower than character-only ones, but further
>optimization is probably possible.
>FWIW, with (open "/dev/stdin") and the same sample.txt, I find the SBCL script to take between 50% and 65% the runtime of the Python on FreeBSD and MacOS x86-64, and in a Debian x86-64 VM. Can't explain this difference in our findings.
This is how you get the attention of retired CL devs huh