Optimize generating UUIDs from strings

[jgaskins]

I'm building a driver for Neo4j and wanted to check on the overhead of generating UUIDs from strings since it's common to store UUIDs as strings in Neo4j. While it was still really good (1M UUIDs/sec), I noticed that UUID incurred a bunch of heap allocations for hardcoded arrays and intermediate strings, so I wanted to see if it could be improved.

In total, generating a UUID from a 36-char string involved creating 2 intermediate arrays and 32 intermediate strings (each hex pair in the hardcoded array has one within the loop and another in string_has_hex_pair_at!). Moving these to use stack-based values instead of heap, I was able to get a 4x performance boost.

➜  Code crystal build --release benchmark_optimized_uuid.cr
➜  Code ./benchmark_optimized_uuid
59c87908-4c45-4a94-b45f-2d338c2b2e17
59c87908-4c45-4a94-b45f-2d338c2b2e17
   string   1.03M (970.15ns) (± 0.44%)  688 B/op   4.11× slower
optimized   4.23M (236.14ns) (± 0.59%)    0 B/op        fastest

Benchmark code

[straight-shoota]

There is even more room for improvement.

The conversion of hex pairs is duplicatesdin the main method and string_has_hex_pair_at!. The helper method should directly return the byte value if it is successfully read.

[asterite]

Awesome! I don't know how those hardcoded arrays passed a previous review.

By the way, for those who wondered about a use case for to_i and friends from a slice instead of a string, here's one :-)

[asterite]

(though the current code will probably be faster than to_u8 on a slice because it goes straight to the point, but this is just a guess)

[ysbaddaden]

Or, since strings are immutable, maybe String#[offset, length] could return a sub String with a pointer to the parent String allocation, instead of always allocate/copy? It would be simpler than going through a Slice.

[asterite]

@ysbaddaden The problem is that a String knows its bytesize and utf-8 size, and that's right at the beginning of a String. Another idea would be to have String be a sort of a union (as in C union) where it can be an inlined string or a string reference to some other string. But then the problem with that is taking a small substring from a huge string and never being able to free the huge string...

I think for performance it's better to go to Slice with to_slice.

[jgaskins]

to_i and friends from a slice instead of a string

This is actually kinda where I was trying to go with this, but I figured I'd go with the smaller change. :-)

The conversion of hex pairs is duplicatesdin the main method and string_has_hex_pair_at!. The helper method should directly return the byte value if it is successfully read.

I found so many roadblocks trying to do that the first time (basically, I felt I had to choose between two potential nil values with to_u8? or a different error with to_u8) but it turns out this does indeed double performance again — we're now up to 8x.

➜  Code crystal build --release benchmark_optimized_uuid.cr && ./benchmark_optimized_uuid
df817978-7772-49fb-8b2f-6293a8e212db
df817978-7772-49fb-8b2f-6293a8e212db
   string   1.04M ( 961.5ns) (± 0.37%)  688 B/op   8.19× slower
optimized   8.52M (117.33ns) (± 0.46%)    0 B/op        fastest

[asterite]

Another optimization could be to work directly with the return value from string.to_slice instead of string. For example doing string[i] will check if the string is ascii-only and then index fast into it, otherwise it will have to go utf-8 char per char to check that. Most probably the string will be ascii-only, but why do the check all the time if we can skip that? (the only problem is that you'll have a byte, but you can turn that into a char with chr, or maybe it's faster not do use to_u8?, but at that point the performance gain won't be much, I think)

[yxhuvud]

Or, since strings are immutable, maybe String#[offset, length] could return a sub String with a pointer to the parent String allocation, instead of always allocate/copy? It would be simpler than going through a Slice.

@ysbaddaden One of the main downsides with this is that it silently can use up a lot of memory, if the substrings have a longer life time than the parent string. Java used to have substrings behave like you suggests here but moved away from it.

[sdogruyol]

Thank you @jgaskins 👍