Jon Chambers writes "Because UUID strings are of a known structure and length (32 hexadecimal digits and four dashes) and because UUIDs are exactly 128 bits in length, we know exactly how each character in a UUID string maps to bits in the parsed UUID. We always know, for example, that the first character in a UUID string maps to the four highest bits in the UUID, the second character maps to the four bits below that, and so on.
With that knowledge, we can cut out a lot of the generality and bounds-checking we'd normally expect of a string-to-number parser. I've built an implementation with that in mind: https://github.com/jchambers/fast-uuid/blob/master/src/main/java/com/eatthepath/uuid/FastUUID.java#L108.
In benchmarks ( https://github.com/jchambers/fast-uuid/blob/master/benchmark/src/main/java/com/eatthepath/UUIDBenchmark.java#L55-L63 ),
this implementation is about six times faster than the current JDK
implementation (9.0.4+11) and 14 times faster than the implementation in
1.8."
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/051134.html
Some of the improvement comes from being stricter about the accepted format, thus retrofitting this to UUID#fromString will likely require maintaining the existing implementation as a fallback.
With that knowledge, we can cut out a lot of the generality and bounds-checking we'd normally expect of a string-to-number parser. I've built an implementation with that in mind: https://github.com/jchambers/fast-uuid/blob/master/src/main/java/com/eatthepath/uuid/FastUUID.java#L108.
In benchmarks ( https://github.com/jchambers/fast-uuid/blob/master/benchmark/src/main/java/com/eatthepath/UUIDBenchmark.java#L55-L63 ),
this implementation is about six times faster than the current JDK
implementation (9.0.4+11) and 14 times faster than the implementation in
1.8."
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/051134.html
Some of the improvement comes from being stricter about the accepted format, thus retrofitting this to UUID#fromString will likely require maintaining the existing implementation as a fallback.
- relates to
-
JDK-8196331 Optimize Character.digit for latin1 input
- Resolved