Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!jg
From: jg@crl.dec.com (Jim Gettys)
Newsgroups: comp.windows.x
Subject: Re: More than 4096 bytes per write to an Xserver on a Sun?
Message-ID: <1991Feb18.194034.24284@crl.dec.com>
Date: 18 Feb 91 19:40:34 GMT
References: <1991Feb18.184330.26090@ssd.kodak.com>
Sender: news@crl.dec.com (USENET News System)
Reply-To: jg@crl.dec.com (Jim Gettys)
Organization: DEC Cambridge Research Lab
Lines: 21

There are a number of buffers involved.  One of them is in Xlib,
and is (currently) hardwired in size.  It might make sense to make it
the same size as the socket buffer. There is a compile time
constant in Xlib currently that determines the buffer size.  
And there are socket buffers on either side of the connection
(Xlib and X server).

No one has looked into the performance tradeoffs of socket buffers
vs. library buffers since X version 6 days (when I last did some...)!  
I encourage someone to do some careful performance work.

Note there is a tradeoff here; you don't want to make all buffers 
arbitrarily large; otherwise bad things happen when you want to kill
off applications, not to mention wasting memory.  Basically, you
want the buffers big enough that context switching, etc. is not a significant
component of time used by both client and server.  But I suspect somewhat
larger buffers would probably be a win these days; X version 6 was before
the Berkeley TCP implementation piggybacked ack's, and having more packets
go out before an ack is necessary would probably be a win on the net.
But I have no data to back this guesstimate up....
				- Jim