Will you make a patch to the 2.x branch as well? The project I work on currently uses the 2.0.1 implementation and we would rather avoid having to change API to take advantageof this.
regards Andre -----Original Message----- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 2:11 PM To: Commons HttpClient Project Subject: Re: Performance Makes sense. I'll start working on a patch. Oleg On Wed, 2004-09-01 at 19:43, Bjarne Rasmussen wrote: > Hi Oleg, > > Forgot to mention: > > It's not that BufferedInputStream#reset is better or faster than > PushbackInputStream#unread. The BufferedInputStream merely supports > mark/reset as a side-effect of doing buffering. The PushbackInputStream > doesn't buffer. From HttpParser: > > public static byte[] readRawLine(InputStream inputStream) throws > IOException { > ByteArrayOutputStream buf = new ByteArrayOutputStream(64); > int ch; > while ((ch = inputStream.read()) >= 0) { > buf.write(ch); > if (ch == '\n') { > break; > } > } > if (buf.size() == 0) { > return null; > } > return buf.toByteArray(); > } > > With PushbackInputStream every call to read will result in a JNI call > in the underlying SocketInputStream. With BufferedInputStream the socket > data is sucked in in 2K blocks thus vastly reducing the amount of JNI > we're doing. > > Thanks, > Bjarne. > > >>> [EMAIL PROTECTED] 9/1/2004 1:30:13 PM >>> > Bjarne, > > Could you define 'considerably' in some ANSI units? ;-) > > I have just recently dealt with this problem. The empirical data that > I > got appears to suggest that there's a (more or less) constant delta in > performance of ~2-3ms, which only makes a difference for relatively > small payloads. For more or less real-life scenarios HttpClient should > be at least as fast or faster than HttpUrlConnection > > http://marc.theaimsgroup.com/?l=httpclient-commons-dev&m=109300858528261&w=2 > > > I'll re-run the tests to see if this change does result in noticeable > performance gains and poke around the Java source code to see if > there's > indeed a reason for PushbackInputStream#unread to be slower than > BufferedInputStream#reset > > Thanks > > Oleg > > > > On Wed, 2004-09-01 at 18:27, Bjarne Rasmussen wrote: > > We found a small performance discrepancy between Java's > > HttpURLConnection and HttpClient. Disabling stale connection checks > > helps but HttpURLConnection is still faster for small payloads. > Making > > the following change to HttpConnection.java (line 689 in version > 2.0.1) > > speeds things up considerably: > > > > inputStream = new BufferedInputStream(socket.getInputStream()); > > > > The BufferedInputStream's mark/reset methods can be used in place of > > PushbackInputStream.unread, e.g.: > > > > this.socket.setSoTimeout(timeout); > > inputStream.mark(1); > > int byteRead = inputStream.read(); > > if (byteRead != -1) { > > inputStream.reset(); > > LOG.debug("Input data available"); > > result = true; > > } else { > > LOG.debug("Input data not available"); > > } > > > > Thanks, > > Bjarne. > > > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]