You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Joe Barnett (Created) (JIRA)" <ji...@apache.org> on 2011/11/15 02:07:51 UTC

[jira] [Created] (LANG-770) StringUtils.join(Object[]) performance issue if .toString() is not trivial

StringUtils.join(Object[]) performance issue if .toString() is not trivial
--------------------------------------------------------------------------

                 Key: LANG-770
                 URL: https://issues.apache.org/jira/browse/LANG-770
             Project: Commons Lang
          Issue Type: Bug
            Reporter: Joe Barnett


I have some code that builds syntax trees, and then uses a combination of TreeNode.toString() and StringUtils.join() to recursively convert that syntax tree to a String representation.

example .toString() of a SumNode class, where children is a TreeNode[]:

public String toString() {
    return StringUtils.join(children, "+");
}

The problem is, StringUtils.join(Object[], String, int, int) is trying to be too smart about preallocating the StringBuffer size it uses internally, as it does:

bufSize *= ((array[startIndex] == null ? 16 : array[startIndex].toString().length())
                        + separator.length());

followed by implicitly calling .toString() on each object in the array:

buf.append(array[i]);

For deep syntax trees, this results in incredibly bad performance, as when traversing the syntax tree, every time we go to the first node, we re-expand the entire tree below that node (which does the same thing with the first node below that, etc).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (LANG-770) StringUtils.join(Object[]) performance issue if .toString() is not trivial

Posted by "Marcos Vinícius da Silva (Commented JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/LANG-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227221#comment-13227221 ] 

Marcos Vinícius da Silva commented on LANG-770:
-----------------------------------------------

Seems that the piece of code in the description doesn't exists anymore. The initial buffer size is being calculated as:

{code}
int noOfItems = endIndex - startIndex;
....
StringBuilder buf = new StringBuilder(noOfItems * 16);
{code}
Using this implementation solves the issue?
                
> StringUtils.join(Object[]) performance issue if .toString() is not trivial
> --------------------------------------------------------------------------
>
>                 Key: LANG-770
>                 URL: https://issues.apache.org/jira/browse/LANG-770
>             Project: Commons Lang
>          Issue Type: Bug
>            Reporter: Joe Barnett
>
> I have some code that builds syntax trees, and then uses a combination of TreeNode.toString() and StringUtils.join() to recursively convert that syntax tree to a String representation.
> example .toString() of a SumNode class, where children is a TreeNode[]:
> public String toString() {
>     return StringUtils.join(children, "+");
> }
> The problem is, StringUtils.join(Object[], String, int, int) is trying to be too smart about preallocating the StringBuffer size it uses internally, as it does:
> bufSize *= ((array[startIndex] == null ? 16 : array[startIndex].toString().length())
>                         + separator.length());
> followed by implicitly calling .toString() on each object in the array:
> buf.append(array[i]);
> For deep syntax trees, this results in incredibly bad performance, as when traversing the syntax tree, every time we go to the first node, we re-expand the entire tree below that node (which does the same thing with the first node below that, etc).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[jira] [Closed] (LANG-770) StringUtils.join(Object[]) performance issue if .toString() is not trivial

Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LANG-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell closed LANG-770.
------------------------------

    Resolution: Not A Problem

Agreed. Resolving this as Not A Problem.
                
> StringUtils.join(Object[]) performance issue if .toString() is not trivial
> --------------------------------------------------------------------------
>
>                 Key: LANG-770
>                 URL: https://issues.apache.org/jira/browse/LANG-770
>             Project: Commons Lang
>          Issue Type: Bug
>            Reporter: Joe Barnett
>
> I have some code that builds syntax trees, and then uses a combination of TreeNode.toString() and StringUtils.join() to recursively convert that syntax tree to a String representation.
> example .toString() of a SumNode class, where children is a TreeNode[]:
> public String toString() {
>     return StringUtils.join(children, "+");
> }
> The problem is, StringUtils.join(Object[], String, int, int) is trying to be too smart about preallocating the StringBuffer size it uses internally, as it does:
> bufSize *= ((array[startIndex] == null ? 16 : array[startIndex].toString().length())
>                         + separator.length());
> followed by implicitly calling .toString() on each object in the array:
> buf.append(array[i]);
> For deep syntax trees, this results in incredibly bad performance, as when traversing the syntax tree, every time we go to the first node, we re-expand the entire tree below that node (which does the same thing with the first node below that, etc).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira