Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 22297 invoked from network); 16 Jan 2010 02:05:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Jan 2010 02:05:16 -0000 Received: (qmail 59613 invoked by uid 500); 16 Jan 2010 02:05:15 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 59487 invoked by uid 500); 16 Jan 2010 02:05:15 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 59466 invoked by uid 99); 16 Jan 2010 02:05:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Jan 2010 02:05:15 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Jan 2010 02:05:14 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 716FB234C4AA for ; Fri, 15 Jan 2010 18:04:54 -0800 (PST) Message-ID: <736691281.284461263607494463.JavaMail.jira@brutus.apache.org> Date: Sat, 16 Jan 2010 02:04:54 +0000 (UTC) From: "Tony Poppleton (JIRA)" To: dev@hc.apache.org Subject: [jira] Issue Comment Edited: (HTTPCORE-212) Minor performance improvements In-Reply-To: <1720885405.251261263514734726.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HTTPCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801066#action_12801066 ] Tony Poppleton edited comment on HTTPCORE-212 at 1/16/10 2:04 AM: ------------------------------------------------------------------ Actually, one last change to the Host patch, instantiating the CharArrayBuffer with the computed length rather than 32 yields a measurable 30% performance increase with a hostname of "localhost". Sebb has just comitted a patch so rather than adding another patch the single line to change is line 172 to become: CharArrayBuffer buffer = new CharArrayBuffer(this.hostname.length() + 6); Also could add a comment along the lines of //the highest port number is 65535, which is length 6 with the addition of the colon Thanks was (Author: moqtada): Actually, one last change to the Host patch, instantiating the CharArrayBuffer with the computed length rather than 32 yields a measurable 30% performance increase with a hostname of "localhost". Sebb has just comitted a patch (with a spurious addition of trailing white spaces in another method?) so rather than adding another patch the single line to change is line 172 to become: CharArrayBuffer buffer = new CharArrayBuffer(this.hostname.length() + 6); Also could add a comment along the lines of //the highest port number is 65535, which is length 6 with the addition of the colon Thanks > Minor performance improvements > ------------------------------ > > Key: HTTPCORE-212 > URL: https://issues.apache.org/jira/browse/HTTPCORE-212 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore > Reporter: Tony Poppleton > Priority: Minor > Fix For: 4.1-beta1 > > Attachments: BasicLineParser.java.patch, BasicLineParser.java.patch2, BasicLineParser.java.patch3, HttpHost.java.patch, HttpHost.java.patch2, HttpHost.java.patch3, HttpHostBenchmark.java > > > JProfiler highlighted a few minor bottlenecks in HttpCore, and two patches are attached. > Neither of these two patches has been benchmarked in a proper fashion, I just observed that they dropped of the JProfiler radar (which isn't a thorough way of doing this and may be wrong!). Could someone with a benchmarking suite already setup please test these patches for performance to confirm they are indeed faster and also if possible ascertain how much faster. > The first patch is to remove the unnecessary creation of a CharArrayBuffer in HttpHost.toHostString. In cases without a port, there is no object creation at all now, and in cases with a port then Java string concatenation is used (and optimized away in recent JVMs). > The second patch is more involved and affects BasicLineParser. Given that all of my responses are being processed with this class, I decided I should look at optimizing it. The main culprit is the string creation in CharArrayBuffer.substringTrimmed which is only required to be able to call the Java Integer.parseInt method. I normally prefer using Java classes where possible, however this patch implements a custom parseInt method which also removes the need for the indexOf operation (so the CharArrayBuffer/String is now only scanned once rather than twice). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org