UUID == String
Table of Contents
What?
When learning CoreData, we had the option to create our model with an identifier typed either as a UUID or a String. I chose using a UUID for two reasons:
- It’s a type specifically used for identifying things, so the specialization makes sense to me and clearly communicates intent to other developers
- I hypothesized that it would result in faster comparison calculations.
A UUID, if you weren’t aware, is a specifically formatted hexadecimal string, such as 1C0E5B90-DEB3-4CAE-BDFD-BDDB29A78007. I’m not sure how the data is being stored internally, but given that it’s hexadecimal, I felt safe in the assumption that it would be stored in a format other than a string.
This following statement has not been authorized any governing bodies and is purely speculation, but given my basic understanding of computer science, I believe it would be faster to compare two numerical values as equal (or not) than it would be to compare two strings.
So, when the app I mentioned earlier downloads a new object and searches through the local cached database, it compares the id of the downloaded entry with all the cached entries to see if it already exists locally (to then update it, if it does). Now, to be fair, our app was small enough that there would be completely no noticeable difference between the two, but I still chose it on principle (and for the intent reason mentioned above, as well).
Anyways, a week or so passed and my curiosity finally got the better of me, so I created a small benchmarking app to compare the speed of the two different methods, which I thought were quite interesting.
HOW DO
My methodology was such that anyone who wanted to run their own tests can adjust the number of iterations to reasonably the capabilities of whatever device they decide to run it on (I ran it on my 2017 i5 iMac and iPhone 6s). The app then creates an array of UUIDs and an array of Strings each with the capacity of the iterations requested. I also allowed varying the number of times the calculation would match vs the number of times it wouldn’t, as those two differing variations could differ in timing (the theory being that, if something matches, it has to iterate over the entire sequence to confirm, but if it doesn’t it can exit as soon as something doesn’t match). Additionally, I also made sure that both arrays had the same proportion of matching vs unmatching members. Finally I shuffled both arrays to add the element of averaging randomization. Finally, the actual benchmark was to take a UUID generated at the launch of the app and compare it to all the values of each array, once as a UUID compared against UUIDs and again as a String compared against Strings.
It’s important to note that the results will vary depending on the machine you run it on (obviously), but more importantly, they will vary based on whether you compile in debug mode or release mode (release mode makes many optimizations).
The Conclusion
I am happy to announce I was at least partially right! UUIDs are definitely faster to compare than strings! And, on my iPhone specifically, it could be a little over twice as fast. I still can’t say how their data is stored, but it almost surely isn’t as a String.
If you want to pick apart my benchmarking and tell me what I did wrong, the code is here.
What?
When learning CoreData, we had the option to create our model with an identifier typed either as a UUID or a String. I chose using a UUID for two reasons:
- It’s a type specifically used for identifying things, so the specialization makes sense to me and clearly communicates intent to other developers
- I hypothesized that it would result in faster comparison calculations.
A UUID, if you weren’t aware, is a specifically formatted hexadecimal string, such as 1C0E5B90-DEB3-4CAE-BDFD-BDDB29A78007. I’m not sure how the data is being stored internally, but given that it’s hexadecimal, I felt safe in the assumption that it would be stored in a format other than a string.
This following statement has not been authorized any governing bodies and is purely speculation, but given my basic understanding of computer science, I believe it would be faster to compare two numerical values as equal (or not) than it would be to compare two strings.
So, when the app I mentioned earlier downloads a new object and searches through the local cached database, it compares the id of the downloaded entry with all the cached entries to see if it already exists locally (to then update it, if it does). Now, to be fair, our app was small enough that there would be completely no noticeable difference between the two, but I still chose it on principle (and for the intent reason mentioned above, as well).
Anyways, a week or so passed and my curiosity finally got the better of me, so I created a small benchmarking app to compare the speed of the two different methods, which I thought were quite interesting.
HOW DO
My methodology was such that anyone who wanted to run their own tests can adjust the number of iterations to reasonably the capabilities of whatever device they decide to run it on (I ran it on my 2017 i5 iMac and iPhone 6s). The app then creates an array of UUIDs and an array of Strings each with the capacity of the iterations requested. I also allowed varying the number of times the calculation would match vs the number of times it wouldn’t, as those two differing variations could differ in timing (the theory being that, if something matches, it has to iterate over the entire sequence to confirm, but if it doesn’t it can exit as soon as something doesn’t match). Additionally, I also made sure that both arrays had the same proportion of matching vs unmatching members. Finally I shuffled both arrays to add the element of averaging randomization. Finally, the actual benchmark was to take a UUID generated at the launch of the app and compare it to all the values of each array, once as a UUID compared against UUIDs and again as a String compared against Strings.
It’s important to note that the results will vary depending on the machine you run it on (obviously), but more importantly, they will vary based on whether you compile in debug mode or release mode (release mode makes many optimizations).
The Conclusion
I am happy to announce I was at least partially right! UUIDs are definitely faster to compare than strings! And, on my iPhone specifically, it could be a little over twice as fast. I still can’t say how their data is stored, but it almost surely isn’t as a String.
If you want to pick apart my benchmarking and tell me what I did wrong, the code is here.