[flexi-streams-devel] Re: New release 0.13.0 (Was: New release 0.11.1)

[Anton Vodonosov]

Edi Weitz:
> 
> On Sun, 29 Apr 2007 22:43:44 +0400, Vodonosov Anton <vodonosov at 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: flexi.diff
Type: application/octet-stream
Size: 3297 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/flexi-streams-devel/attachments/20071109/7a52777b/attachment.obj>