Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sat, 14 Mar 2015 12:49:38 +0000 (UTC)
From: "Thomas Neidhart (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12684159.1386822103000.94367.1426337378442@Atlassian.JIRA>
In-Reply-To: <JIRA.12684159.1386822103000@Atlassian.JIRA>
References: <JIRA.12684159.1386822103000@Atlassian.JIRA>
 <JIRA.12684159.1386822103791@arcas>
Subject: [jira] [Commented] (LANG-935) Possible performance improvement on
 string escape functions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Thomas Neidhart commented on LANG-935:
--------------------------------------

thats not the edge case I was talking about.
The problem is not with the way the LookupTranslator is used for the escapeXXX methods, but that the LookupTranslator could be used in different scenarios as it is a public class.

I am a bit busy right now, but will come up with a testcase to illustrate the problem if you still do not see it.

Imho, it would be better to use the approach from the original proposal to improve the escapeXXX methods, but leave the LookupTranslator untouched for now.

> Possible performance improvement on string escape functions
> -----------------------------------------------------------
>
>                 Key: LANG-935
>                 URL: https://issues.apache.org/jira/browse/LANG-935
>             Project: Commons Lang
>          Issue Type: Improvement
>          Components: lang.text.translate.*
>    Affects Versions: 3.1
>            Reporter: Peter Wall
>            Priority: Minor
>              Labels: performance
>             Fix For: Patch Needed
>
>         Attachments: tempproject1.zip
>
>
> The escape functions for HTML etc. use the same code and the same initialisation tables for the escape and unescape functions, and while this is an elegant approach it leads to a number of deficiencies:
> 1. The code is very much less efficient than it could be
> 2. A new output string is created even when no conversion is required
> 3. No mapping is provided for characters that do not have a specific representation (for example HTML 0x101 should become &amp;#257; )
> The proposal is to use a new mapping technique to address these issues


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