Avoid String concatenation for lookup in StaticMessageSource

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!

[stsypanov]

Currently StaticMessageSource employs String composed of key and stringified Locale as key in map:

publicclassStaticMessageSourceextendsAbstractMessageSource {
/** Map from 'code + locale' keys to message Strings. */privatefinalMap<String, String> messages = newHashMap<>();
privatefinalMap<String, MessageFormat> cachedMessageFormats = newHashMap<>();
//...
}

As a result at each call to Map::get/Map::put we have to concat Strings resulting in allocations of StringBuilder and copying char[]. Instead I propose to use separately defined immutable Key.

I've tested behaviour with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
publicclassLocaleToStringBenchmark {
@BenchmarkpublicObjectconcatenation(Datadata) {
returndata.code + '_' + data.locale;
}
@BenchmarkpublicObjectcompositeKey(Datadata) {
returnnewKey(data.code, data.locale);
}
@BenchmarkpublicinthashCodeCompositeString(Datadata) {
returndata.compositeString.hashCode();
}
@BenchmarkpublicinthashCodeCompositeKey(Datadata) {
returndata.compositeKey.hashCode();
}
@BenchmarkpublicbooleanequalsCompositeString(Datadata) {
returndata.compositeString.equals(data.anotherCompositeString);
}
@BenchmarkpublicbooleanequalsCompositeKey(Datadata) {
returndata.compositeKey.equals(data.anotherCompositeKey);
}
@State(Scope.Thread)
publicstaticclassData {
privatefinalStringcode = "code1";
privatefinalLocalelocale = Locale.getDefault();
privatefinalKeycompositeKey = newKey(code, locale);
privatefinalStringcompositeString = code + '_' + locale;
privatefinalKeyanotherCompositeKey = newKey(code, locale);
privatefinalStringanotherCompositeString = code + '_' + locale;
}
privatestaticfinalclassKey {
privatefinalStringcode;
privatefinalLocalelocale;
privateKey(Stringcode, Localelocale) {
this.code = code;
this.locale = locale;
}
@Overridepublicbooleanequals(Objecto) {
if (this == o) returntrue;
if (o == null || getClass() != o.getClass()) returnfalse;
Keykey = (Key) o;
if (!code.equals(key.code)) returnfalse;
returnlocale.equals(key.locale);
}
@OverridepublicinthashCode() {
return31 * code.hashCode() + locale.hashCode();
}
}
}

Patched consumes much less memory on key allocation and does it faster, performance of equals/hashCode is mostly the same (tested at work on i7-7700):

JDK 8
Mode Cnt Score Error Units
compositeKey avgt 25 5,134 ± 0,274 ns/op
concatenation avgt 25 67,999 ± 5,872 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 224,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,229 ± 0,161 ns/op
equalsCompositeString avgt 25 6,447 ± 0,448 ns/op
hashCodeCompositeKey avgt 25 2,584 ± 0,054 ns/op
hashCodeCompositeString avgt 25 2,069 ± 0,028 ns/op
JDK 11
Mode Cnt Score Error Units
compositeKey avgt 25 5,851 ± 0,271 ns/op
concatenation avgt 25 61,900 ± 4,406 ns/op
compositeKey:·gc.alloc.rate.norm avgt 25 24,000 ± 0,001 B/op
concatenation:·gc.alloc.rate.norm avgt 25 168,000 ± 0,001 B/op
equalsCompositeKey avgt 25 3,177 ± 0,254 ns/op
equalsCompositeString avgt 25 5,787 ± 0,305 ns/op
hashCodeCompositeKey avgt 25 2,947 ± 0,105 ns/op
hashCodeCompositeString avgt 25 2,187 ± 0,083 ns/op

[stsypanov]

@jhoeller I've slightly simplified the patch to use Array.asList

[stsypanov]

@jhoeller hello, any updates on this?

[jhoeller]

On review, I'll rather go with a nested Map<String, Map<Locale, ...>> structure here, similar to ReloadableResourceBundleMessageSource. We can even have a single structure with a message holder that contains both the raw message and a lazily resolved MessageFormat instance.

As a side note, part of the original design of StaticMessageSource was to have a human-readable map representation in its toString() output. Rendering a flat map with its concatenated String keys was a nice benefit there; fortunately, even the nested map structure looks alright there now.

I'll repurpose this issue accordingly. Thanks for the PR, in any case!