Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <1292434485.253871263519414542.JavaMail.jira@brutus.apache.org>
Date: Fri, 15 Jan 2010 01:36:54 +0000 (UTC)
From: "Tony Poppleton (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Subject: [jira] Commented: (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


    [ https://issues.apache.org/jira/browse/HTTPCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800491#action_12800491 ] 

Tony Poppleton commented on HTTPCORE-212:
-----------------------------------------

Understood about the Java 1.3, however I would still say this is a better implementation.  It uses native Java classes rather than custom ones, and if users of Java 1.3 were desperate for a performance boost then they would upgrade Java and get a double win.  The patched code is also simpler to read.

In addition, the CharArrayBuffer was instantiated with an arbitrary size, which could either be too small (and grow) or too large - either way it is inefficient.

Also, the toURI method in HttpHost could probably benefit from the same usage of String rather than CharArrayBuffer.

> 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
>         Attachments: BasicLineParser.java.patch, BasicLineParser.java.patch2, HttpHost.java.patch, HttpHost.java.patch2
>
>
> 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