[jira] [Commented] (LANG-770) StringUtils.join(Object[]) performance issue if .toString() is not trivial
[
https://issues.apache.org/jira/browse/LANG-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CSV-34) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/CSV-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227264#comment-13227264 ] Emmanuel Bourg commented on CSV-34: --- Eventually I removed the volatile modifier, it was slowing the parser by about 5% in my tests. I replaced the clones by a constructor call as you suggested. CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: CSV-34 URL: https://issues.apache.org/jira/browse/CSV-34 Project: Commons CSV Issue Type: Bug Reporter: Sebb Fix For: 1.0 Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- 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] (CSV-34) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/CSV-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227307#comment-13227307 ] Sebb commented on CSV-34: - That's quite surprising. Obviously volatile will have some overhead, but I'm surprised it is as much as that, but then there are quite a few variables to be checked. CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: CSV-34 URL: https://issues.apache.org/jira/browse/CSV-34 Project: Commons CSV Issue Type: Bug Reporter: Sebb Fix For: 1.0 Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- 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-791) Introduce Triple/Triad (3-tuple) similar to Pair
[ https://issues.apache.org/jira/browse/LANG-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-791. -- Resolution: Duplicate https://svn.apache.org/repos/asf/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Triple.java :) Introduce Triple/Triad (3-tuple) similar to Pair Key: LANG-791 URL: https://issues.apache.org/jira/browse/LANG-791 Project: Commons Lang Issue Type: New Feature Components: lang.tuple.* Affects Versions: 3.1 Reporter: Eugen Paraschiv Priority: Minor It would be very useful to have a 3-tuple similar to the 2-tuple (Pair) that already exists. The decision of choosing to use a Triple/Triad instead of an n-tuple would not be as straightforward as using a Pair, but a Triple is still a simple enough and very common use-case, and having the implementation as part of commons-lang should make sense. -- 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
