lstreams (was Re: package badness)

Hrvoje Niksic writes: Before lstreams, stdio was not used for saving buffers. Prior to 19.12, XEmacs saved a buffer by doing two write() operations--- the first from beginning of buffer to the gap and the second from the gap to end of buffer. Fast. At present, we copy data from an Emacs buffer to stack buffer. Then from a stack buffer to an lstream buffer. Then finally we write() it to disk. Slow. The same sort of gup is done in insert-file-contents-internal. Why would lstreams be slower than stdio for reading Lisp? Lstreams do more. Stdio only allows you to unget one character. lstreams allow unlimited unget, and so an extra index must be checked for every call to (the macroized) Lstream_getc. Lstream_getc is run for every char read from a Lisp file. The extra instructions add up. Lstream_getc also increments a byte counter that stdio almost certainly would not be maintaining. More instructions. This is from just eyeballing the code, so I could be wrong. For the binary coding system, we could probably go back to just doing two write() calls for saving buffers. But write-region-internal is trying to do something with annotations that I've never bothered to unravel, so maybe we can't. It's on my list of things to look at one day.