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

Remi Forax forax at univ-mlv.fr
Sat Jul 19 16:47:52 UTC 2014

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

More information about the core-libs-dev mailing list