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

[Martin Buchholz]

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.