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

Thanks.

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 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to