Edi Weitz:
On Sun, 29 Apr 2007 22:43:44 +0400, Vodonosov Anton vodonosov@mail.ru wrote:
I have a new version, with better performance (see attached diff of output.lisp against 0.11.2).
I've finally found some time to think about this. I've now released a new version which is based on your ideas but which (I hope) is a bit more elegant and maybe even a bit faster for the case where characters are output individually.
This new release also fixes a glaring bug in STREAM-WRITE-BYTE.
Thanks a lot for your patch, Edi.
PS: And the next time please send a patch without TAB characters... :)
Hi. Glad you committed it.
Sorry about tabs. You may consider setting emacs variable indent-tabs-mode to nil in your sources.
Few days ago I've tried to measure performance improvement gained by buffering in stream-write-sequence. It turned out that in real word scenarios no improvement at all, because underlying stream always provides necessary buffering.
For example, to notice changes in performance when working with file, we must use unbuffered file stream, which is of course very uncommon (moreover, in case of normal, buffered, file stream performance is slightly worse because we do some additional work on our side; but you must do lot of output to notice this).
Therefore, I've decided to test it with network stream. I've setup hunchentoot and configured simple easy-handler that just return a 10k string. Also, I've changed the make-socket-stream function to create unbuffered socket (:buffering :none in sbcl).
On the other host the was drakma performing a hundred of requests to this handler.
I've tested this setup with two versions of flexi streams: 0.11.0 - without buffering and 0.13.1 - with buffering. It is surprising (for me) that in this case there was no performance difference too.
Using sniffer (ethreal) I've discovered that even in case if we do not do any buffering on sbcl side, buffering is anyway performed - by TCP implementation. When we do lot of write-byte it sends first packet with data length = 1, but all subsequent packets are of size > 1k. Looks like they have some micro timeout after our write-byte to see whether we will do write-byte again.
Maybe this buffering in stream-write-sequence is unnecessary...
Best regards, -Anton
P.S. There is a little test for stream-line-column function in the attach.