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]
