Measuring performance of Java UUID.fromString() (or lack thereof)

aka “Why is UUID.fromString() so slow?”

Background

Similar to my recent adventure into evaluating performance of String.format() for simple String concatenation, I found another potentially meaningful case of widely used (and useful) JDK-provided functionality that seems to significantly under-perform: decoding of from a String:

UUID uuid = UUID.fromString(request.getParameter("uuid"));

This was found to be a hot spot on profiling done for a web service. Given that decoding should not really be that complicated compared to, say, generating UUIDs, this seemed odd.
(note: I am not the first developer to have noticed this, see f.ex this blog post from 2015)

Given that I once wrote (and still maintain) the popular java-uuid-generator library — which actually predates addition of in JDK 1.4 by a year or two :) — I thought I could see what is happening and whether I could find and evaluate more efficient alternatives.

And as usual, I’ll reproducible test(s) on https://github.com/cowtowncoder/misc-micro-benchmarks microbenchmark suite.

#include <std-disclaimers.h>

Before proceeding further I think I need to add the usual standard disclaimers about microbenchmarking, results and interpretations: microbenchmarking itself is hard to get right and results (absolute and relative) are never absolute, and beyond being relative are highly contextual: something being 10x or 100x or 1000x slower may or may not be a problem in a given situation.
So I’ll get and show some numbers, talk about them; you may consider using that information if it makes sense for your particular usage.

Does JUG have it? How about Jackson?

Measuring the actual performance of can be useful in estimating the relevance of measurements, but the other important part is to establish potential upper bound on faster implementation.

At first I thought that java-uuid-generator probably has equivalent code I could use. With a bit of digging I found it indeed has this method:

UUID uid = UUIDUtil.uuid(uuidString);

and we can see how its performance ranks compared to JDK implementation.

In addition, I know that Jackson (jackson-databind) also has a rather heavily optimized which could be useful — not exactly as-is, but we can easily copy-paste the logic. So let’s check out that too: Jackson codebase tends to be heavily optimized in many places and I recall having spent some time with UUID handling in particular.

I suspect there are many other implementations out there too that I could have benchmarked (there are 2 other widely used Java UUID generator libraries, both of which may well have a method for decoding) — if anyone wants to contribute an addition, feel free to submit a PR against https://github.com/cowtowncoder/misc-micro-benchmarks and I can update the results!
But for now let’s see how these initial 3 choices perform.

Test Case & Results, initial

In this case our test set up is quite simple: we pre-construct a set of s (32) using random-number based generation method, then convert them to s: the test consists of rounds of constructing UUIDs back from the 32-element String array.
The test class is (in package ) if you want to have a peek.

Running this test on my set up (Mac Mini (2018) 3.2Ghz 6-core Intel Core i7, JDK 1.8.0_272) gives results like this (note: I trimmed names of test cases to fit results better):

Benchmark                     Mode   Cnt      Score       Error  Units
UUIDFromString.m1_JDK thrpt 15 89175.229 ± 1899.754 ops/s
UUIDFromString.m2_JUG thrpt 15 490052.366 ± 35351.600 ops/s
UUIDFromString.m3_manual thrpt 15 1129569.239 ± 6054.405 ops/s

This gives us rough ratios of performance: using JDK implementation as the baseline, we see that:

  • JDK approach can decode almost 3 million UUIDs per second (per core)
  • java-uuid-generator can decode UUIDs from Strings about 5 times as fast (15 million / sec / core)
  • copy-pasted code from Jackson can decode UUIDs from Strings over 10 times as fast (33 million / sec / core)

So: there is indeed a significant performance overhead with JDK (8) way of doing things. Yet even with it you need to call this method awful lot for it to necessarily matter.

Results with JDK 14

Given that JDK 8 is getting old by now, I decided to try the current stable LTS JDK, JDK 14. To my surprise there was quite a big positive difference — JDK 14 implementation is almost 4x as fast as in Java 8! While not quite as fast as alternatives, performance is rather close to . Jackson’s optimized version is still faster but it’s only by a factor of 3 now.

Benchmark                 Mode   Cnt    Score       Error    Units
UUIDFromString.m1_JDK thrpt 15 358738.222 ± 7188.453 ops/s
UUIDFromString.m2_JUG thrpt 15 529761.948 ± 3866.240 ops/s
UUIDFromString.m3_manual thrpt 15 1181016.727 ± 4541.903 ops/s

Reasons for slowness of Java 8 / UUID.fromString()

One thing that interests me, as usual, is the reason for slowness of Java 8 implementation. I was thinking of profiling it a bit until realizing that someone else had already checked into it: “Micro-optimization for UUID.fromString()” has a good overview of where time is spent, so I won’t repeat it here.

And as to JDK 14, I assume it uses approach similar to what java-uuid-generator does. That approach is probably bit less code than Jackson’s, using simple looping: Jackson, on the other hand, gains more speed but removing looping after first sanity-checking validity of input format.

Next Steps

Given the difference between , Jackson’s decoder, I am tempted to use code from latter to speed up implementation in former — leading to the fascinating idea of releasing a new version of almost 20-years old library (although the oldest version at Maven Central is marked as being from 2005, the first version was actually made available in 2003 or so).
We’ll see — it seems like a nice idea if I find time to do that.

Open Source developer, most known for Jackson data processor (nee “JSON library”), author of many, many other OSS libraries for Java, from ClassMate to Woodstox