Relates :
|
|
Relates :
|
|
Relates :
|
JDK-8006627 did the JavaLangAccess hack to improve UUID.toString() performance: public String toString() { char[] chars = new char[36]; jla.formatUnsignedLong(mostSigBits >> 32, 4, chars, 0, 8); chars[8] = '-'; jla.formatUnsignedLong(mostSigBits >> 16, 4, chars, 9, 4); chars[13] = '-'; jla.formatUnsignedLong(mostSigBits, 4, chars, 14, 4); chars[18] = '-'; jla.formatUnsignedLong(leastSigBits >> 48, 4, chars, 19, 4); chars[23] = '-'; jla.formatUnsignedLong(leastSigBits, 4, chars, 24, 12); return jla.newStringUnsafe(chars); } This is a good performance improvement, but it clashes with Compact Strings which now have to re-compress the resulting char[] array into byte[]. And we know that UUID would always produce Latin1 String. If we follow the same route, and drill more holes in JavaLangAccess to accept Strings with a preset coder, we will also have to take care of the case when Compact Strings are turned off. It might turn beneficial to wait for JDK-8148604 to land, and revert toString() back to plain Java concatenation, letting advanced concat strategies to take care of optimal concat, even in the presence of unsigned long conversions.
|