hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Bigbee <abig...@mitre.org>
Subject Re: Why non-buffered InputStream in HttpClient / HttpParser?
Date Thu, 03 Jul 2003 14:07:41 GMT
On Wednesday, July 2, 2003, at 10:38 PM, Michael Becke wrote:

> I'm not sure if there is a real reason.  It is probably because 
> HttpClient does not do much with the input stream other than read 
> status/headers.  Any large content should be handled by the user and 
> could therefore be buffered.
>
> The socket input stream is also used directly at a number of points to 
> test for content availability so this change might be a little more 
> complicated than just wrapping on another stream.

I'm wondering:   *if* the HttpParser.readLine method (and subsequent 
calls to .readRawLine) is called much more frequently than other 
methods/classes that tap into InputStream, perhaps a start would be to 
modify the code in .readRawLine to use a BufferedReader+ 
BufferedInputStream.  That might yield some significant gains for small 
effort.  I'm just speculating here.


> Perhaps this is something we should look into.  I do not think this 
> will make it into 2.0 but perhaps 2.1.  Have you tried making some 
> modifications for timing purposes?
>
I haven't made any mods to the HttpClient code.  I just ran some tests 
with small classes to compare CPU loading between InputStream reading 
and BufferedReader + BufferedInputStream line reading.  Didn't do any 
timing measurement--might be interesting to see if there are 
significant differences.

Tony



Mime
View raw message