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

[Remi Forax]

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.

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 ?

regards,
Rémi

>
>
> On Fri, Jul 18, 2014 at 6:18 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
>
>> On 19.07.2014 3:07, Martin Buchholz wrote:
>>
>>> I took a quick look at StringJoiner.  It looks to me like this won't be
>>> an optimization, because StringJoiner uses StringBuilder internally, and
>>> will actually perform more total operations.
>>>
>> Unfortunately this is true.
>> Microbenchmarking shows that StringJoiner makes the things 30% slower,
>> which is sad.
>>
>> Then I propose another simple patch giving +15% to the speed:
>>
>> http://cr.openjdk.java.net/~igerasim/8051382/1/webrev/
>>
>> Sincerely yours,
>> Inan
>>
>>