[flexi-streams-devel] Re[2]: New release 0.13.0

[Anton Vodonosov]

Edi Weitz <edi at 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