RFR [8051382] Optimize java.lang.reflect.Modifier.toString() (original) (raw)

Martin Buchholz martinrb at google.com
Sun Jul 20 05:00:57 UTC 2014

On Sat, Jul 19, 2014 at 9:47 AM, Remi Forax <forax at univ-mlv.fr> wrote:

On 07/19/2014 05:58 PM, Martin Buchholz wrote:

StringJoiner seems written in a style suitable for an application, not in a low-level performance-oriented style suitable for a JDK core library. But we can fix that.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ StringJoiner-optimization/ Hi Martin, it's not obvious for me that your implementation is more efficient, if you have a lot of strings, because you store reference to them, you will have references everywhere on heap so toString() will not be very cache friendly. The current implementation that use a StringBuilder will consume more memory but is more cache friendly. In my implementation, the string chars will not even be examined at add() time, and then copied only once at toString() time. In the original, the string chars will be copied twice.

True that in my implementation the String objects themselves are examined twice. I guess that most of the time they will still be in cache.

otherwise, your implementation of merge is weird (or half weird), unlike add, for merge you combine all strings into a unique big string instead of merging the two arrays, is there a reason for that ?

* <p>If the other {@code StringJoiner} is using a different delimiter,
 * then elements from the other {@code StringJoiner} are concatenated

with * that delimiter and the result is appended to this {@code StringJoiner} * as a single element.

we could have different code paths, depending on whether the delimiters were equal.

More information about the core-libs-dev mailing list