Improving performance and reducing object allocations of java.util.UUID to/from string (original) (raw)

Steven Schlansker stevenschlansker at gmail.com
Sat Dec 29 17:25:06 UTC 2012


Hello core-libs-dev,

My company uses UUIDs throughout our software. We recently identified that the java.util.UUID implementations of fromString and toString are horridly inefficient.

An incomplete list of the inefficiencies:

Everyone that I have shown the relevant code to has been horrified by the complete lack of care towards object allocations. While I am a big fan of the "object allocation is free until otherwise proven" philosophy, we traced multiple production problems down to these hotspots.

But instead of just whining about it, I wish to contribute a patch which I believe fixes the problem. This is my first attempt to submit anything to the JDK, so please be nice :-)

My initial attempt has yielded micro benchmarks with very favorable outcomes. By taking the appropriate code from java.lang.Long, modifying it to work on a single pre-allocated array+offset rather than returning a String, and scanning for dashes instead of regex splitting I reduced times 3-6x and object allocations to the low single digits.

My Google Caliper benchmark is available here, to ensure that I have not committed any benchmark sins: https://gist.github.com/4356621

    benchmark instances  Bytes    ns linear runtime

JdkUuidFromString 51.00 1544.0 608.2 ============================== NewUuidFromString 2.00 72.0 179.1 ========

JdkUuidToString 31.00 1720.0 321.4 =============== NewUuidToString 3.00 200.0 51.5 ==

In particular, the reduction of object allocations from ~1.5KB to 72/200 bytes dramatically reduces GC pressure when you sit in a tight loop deserializing millions of UUIDs from strings.

I believe the same patch can (and should?) apply to jdk7u and jdk8, as the code does not seem to have changed.

I would appreciate any feedback on the code style, efficiency, or correctness that you can offer. I have run the "java/util/UUID" jtreg suite against this and it passes. We stole the more thorough Apache Harmony tests for this and they pass as well: https://github.com/stevenschlansker/components-ness-core/blob/master/src/test/java/com/nesscomputing/uuid/TestNessUUID.java

I have not yet secured a CLA, but my company is in the process of signing one.

The rest of the message is a "hg export" of my change set, which is current to the tip of jdk7. Happy holidays, and thank you for your time! Steven Schlansker

HG changeset patch

User Steven Schlansker <steven at nesscomputing.com>

Date 1356737383 0

Node ID a812c963b96f08112f6805cbc380b12af196f788

Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3

java.util.UUID: improve performance of UUID#toString and UUID#fromString by avoiding many unnecessary object allocations.

    benchmark instances  Bytes    ns linear runtime

JdkUuidFromString 51.00 1544.0 608.2 ============================== NewUuidFromString 2.00 72.0 179.1 ========

JdkUuidToString 31.00 1720.0 321.4 =============== NewUuidToString 3.00 200.0 51.5 ==

diff -r 9b8c96f96a0f -r a812c963b96f src/share/classes/java/util/UUID.java --- a/src/share/classes/java/util/UUID.java Mon Jun 27 13:21:34 2011 -0700 +++ b/src/share/classes/java/util/UUID.java Fri Dec 28 23:29:43 2012 +0000 @@ -189,26 +189,79 @@ * described in {@link #toString} * */

@@ -372,19 +425,46 @@ * @return A string representation of this {@code UUID} */ public String toString() {



More information about the core-libs-dev mailing list