Andre, I intend to provide a fix for both 2.0 and HEAD. The fix is pretty straight-forward once you know what needs fixing. So, special thanks go to Bjarne
Oleg On Wed, 2004-09-01 at 21:54, Andre-John Mas wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
