Edi Weitz edi@agharta.de:
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...
Hmmm....
ISTR that I did some simple tests with your patch and that there was a noticeable difference, but I don't have the results anymore. Anyway, I think I'll leave it like it is for now.
Looks like slow network connection between hosts was the bottleneck in my test. I've tried with drakma and hunchentoot on the same computer and indeed, there is a difference, recent flexi-streams is a little faster. This difference doesn't depend on whether socket stream is buffered or no. Therefore I conclude that performance is saved by avoiding internal machinery of write-byte (access to internal slots of stream object, etc. in both flexi-stream and sbcl socket stream).
I was confused because thought that multiple write-byte on socket will result multiple packets to be sent, that would made write-byte on underlying socket stream extremely expensive, and expected radical performance improvement when individual write-byte are avoided.
Best regards, -Anton