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.
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?
Mike
On Wednesday, July 2, 2003, at 03:25 PM, Tony Bigbee wrote:
Hi,
I'm using the Slide webdav client libs (1.0.16) and have noticed a higher than expected CPU load from HttpClient (1.x) doing socket reading.
Closer examination revealed that when I do webdav .puts, the high CPU consumers are .readLine()s calls to the socket. For some
reason, use of the Xrunhprof doesn't give any info on the "bulk" socket writing going on to write file content across the network to > the
webdav server. I've noticed that HttpClient uses unbuffered InputStream is used to grab bytes/chars one at a time from the socket.
Looking at the 2.0 beta 2 code, it appears that HttpParser.readRawLine is doing the same thing -- using unbuffered input classes InputStream/PushbackInputStream.
Is there a strong design consideration that drives the use of unbuffered versus buffered java.io input stream classes? For occasional http connections and very small data sizes,
it's probably not that big of a deal. But for larger volumes, it may add significantly to CPU loading (I've run tests to confirm this with test classes comparing BufferedInputStream versus
InputStream).
Thanks, Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
