hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Poppleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-212) Minor performance improvements
Date Sat, 16 Jan 2010 12:35:54 GMT

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

Tony Poppleton commented on HTTPCORE-212:


Just to clarify, the performance improvement has nothing to do with the custom implementation
of parseInt itself.  The bottleneck was in creating the String from the CharArrayBuffer in
the first place, and the only way to avoid this was to do the custom implementation of parseInt.
 This String creation was being done in two places everytime parseStatusLine was being called,
and as a result CharArrayBuffer.substringTrimmed() was being marked as a bottleneck in JProfiler.

Can I suggest that parseInt be moved either into CharArrayBuffer or a util class (which one?).
 If it goes on CharArrayBuffer, which I would prefer, then we could also add an append method
that takes all the primitives (like in StringBuilder/Buffer), and this can be used to remove
the use of Integer.toString as suggested by Oleg.

I agree that this issue is pretty minor compared to other stuff you are working on, however
I am finding it a useful introduction to the codebase, and would like to spend more time on
it.  I will investigate the package wide changes that you have suggested, and also complete
the benchmark to see if it is actually any faster.

> 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
> 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

View raw message