Re: Performance analysis questions

Rick Troth <>
Date: Fri, 13 May 1994 15:18:23 +0200
Message-id: <>
Precedence: bulk
From: Rick Troth <>
To: Multiple recipients of list <>
Subject: Re: Performance analysis questions 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
On Thu, 12 May 1994, George Phillips wrote:

> Andrew Payne said:
> > ...  Code like this doesn't help (getline() in util.c):
> >
> >           if((ret = read(f,&s[i],1)) <= 0) {
> >
> >Your mileage may vary.
> Whilst looking through the httpd code, I noticed this too. ... 
> This is done because it wants to hand off the file descriptor to
> CGI scripts that handle POSTs.  I'd suggest the right way to fix
> things is to read a bufferful and cat the extra to the scripts that
> need it.  However, a quick hack could double the speed by doing
> read(f, &s[i], 2) because you know that at least CR LF will terminate
> the line. 
	For something totally unrelated,  I wrote my own getline(). 
Trying to adhere to the  "be liberal about what you accept and 
conservative about what you generate"  rule,  it doesn't care 
whether or not there's actually a CR,  just the LF,  and returns the 
length of the string LESS the line terminator(s),  or < 0 on error. 
	I think mine is at least as bad as Rob's above. 
The intent was to replace it (someday) and not have a if/while 
based on characters embedded in the server proper. 
> If it's the header boundary that's a problem, you could
> quadruple the speed with read(f, &s[i], 4) since you have at least
> "GET " for HTTP/0.9 requests and HTTP/1.0 headers will terminate
> with CR LF CR LF (well, they better!).
> 		-- George
	Argh!   This is bad.   Not picking on you,  George, 
but you've presumed on something that a *lot* of people seem to 
presume on.   It should be 
		CR LF [any amount of white space] CR LF 
	There are contemporary systems that CAN NOT generate a 
completely empty line in places.   This is a problem for certain 
mail user agents which don't see the header termination because 
the blank line isn't an "empty line" (cr/lf/cr/lf).   Let the blank 
line be just blank to the eyes,  not necessarily  "empty". 
	Try this: 
	    o   a line of text is NUL terminated 
		(assuming you're coding C on UNIX) [YMMV] 
	    o   when sending "on the wire" append CR & LF 
	    o   when receiving, accept either NL (LF) 
		or CR LF for end-of-line 
	    o   when processing, ignore trailing white space 
Rick Troth <>, Rice University, Information Systems