hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-408) Get rid of CharArrayBuffer
Date Thu, 03 Sep 2015 09:55:45 GMT

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

Oleg Kalnichevski commented on HTTPCORE-408:
--------------------------------------------

Hi Sergey 

Not using {{CharSequence}} from the very start was a mistake, but it was not very useful until
{{StringBuilder}} got introduced with Java 1.5.

I already changed all parsing routines in the trunk (5.0) to use {{CharSequence}} instead
of {{CharArrayBuffer}}. This should have pretty much eliminated most (if not all) copy-before-parse
instances. Message formatters still use {{CharArrayBuffer}} though when writing out message
elements.  Feel free to review the changes in the trunk and improve on them.

Oleg

> Get rid of CharArrayBuffer
> --------------------------
>
>                 Key: HTTPCORE-408
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-408
>             Project: HttpComponents HttpCore
>          Issue Type: Wish
>          Components: HttpCore
>    Affects Versions: Future
>            Reporter: Sergey Vladimirov
>            Priority: Minor
>
> Recently I profiled WEB-oriented application that uses http core and http async client
as libraries. At some point I find some very strange code behavior. URLEncodedUtils creates
new CharArrayBuffer and copies whole string into it every time URI parameters parsing is required.
I find no reason for CharArrayBuffer to be used here except "no other type is allowed"
> After some checking I find out that a lot of code uses the same copy-before-parse technique.
Why? Because currently there is no way to work with wrapped values, to pass string as argument,
etc. 
> So, my proposals are:
> * replace CharArrayBuffer with CharSequence at places where only length() and charAt()
methods are used. Almost all parsing code does not need anything else. Thus allow to pass
StringBuffer / String / CharBuffer as argument.
> * Seriously consider replacing CharArrayBuffer with CharBuffer in all places where data
is read from string. Thus reducing GC and make possible for all methods to use direct memory
access (via DirectCharBuffer*).
> * Consider replacing CharArrayBuffer with StringBuilder or even CharBuffer in places
where data is written into it.
> Let me know if this can be included in 5.0 so I can prepare the patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message