[
https://issues.apache.org/jira/browse/HTTPCORE-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCORE-408.
----------------------------------------
Resolution: Fixed
Fix Version/s: (was: 5.0)
5.0-alpha2
> Get rid of CharArrayBuffer
> --------------------------
>
> Key: HTTPCORE-408
> URL: https://issues.apache.org/jira/browse/HTTPCORE-408
> Project: HttpComponents HttpCore
> Issue Type: Wish
> Components: HttpCore
> Reporter: Sergey Vladimirov
> Priority: Minor
> Fix For: 5.0-alpha2
>
>
> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
