1

I've been trying to build a database of entities using a Dictionary with GUID as key, I just want to know which one is faster, or takes less memory in comparison to others.

Here are the dictionaries with different Key types:

String

public Dictionary<string, Object> unityObjects;

GUID

public Dictionary<System.Guid, Object> unityObjects;

BigInteger

public Dictionary<BigInteger, Object> unityObjects;

The dictionary keys are being generated using System.Guid:

Guid guid = Guid.NewGuid();

// Using string dictionary
unityObjects.Add(guid.ToString(), myObj);

// Using GUID dictionary
unityObjects.Add(guid, myObj);

// Using BigInteger dictionary
BigInteger bigInt = new BigInteger(guid.ToByteArray());
unityObjects.Add(guid, myObj);

Or should I use a smaller unique identifier with an Int32 or Int64 instead of GUID? (Something like below code)

System.Random rng = new System.Random();

byte[] buf = new byte[8];
rng.NextBytes(buf);
long longRand = BitConverter.ToInt64(buf, 0);

// A GUID with Int64 data type
long guid = (System.Math.Abs(longRand % (long.MaxValue - 0)) + 0);
Zoe
  • 27,060
  • 21
  • 118
  • 148
Hasan Bayat
  • 926
  • 1
  • 13
  • 24
  • 6
    " I just want to know which one is faster, or takes less memory in comparison to others." then you should test. – David Browne - Microsoft Apr 27 '19 at 13:07
  • @DavidBrowne-Microsoft Yeah, you're right, but I wanted to know the expert's opinion on this first, plus knowing what's the best approach for having such database GUID keys. – Hasan Bayat Apr 27 '19 at 13:10
  • You're the best expert on your code. You should test your code. – Enigmativity Apr 27 '19 at 13:51
  • Obligatory Eric Lippert link: [Which is faster?](https://ericlippert.com/2012/12/17/performance-rant/) – Jeroen Mostert Apr 27 '19 at 14:06
  • 1
    Actually, a quick google and you could have had your expert view on it. This is just one of many google answer I got. https://stackoverflow.com/questions/5743474/key-performance-for-a-dictionary – Everts Apr 27 '19 at 17:52

1 Answers1

2

Obviously the smaller the data type, the faster it will be. But in order to have unique identifier for your dictionary using GUID is helpful in more than one way. It's a bit slower of course, but it's guaranteed to be unique and created for this purpose only. Anyone who sees a GUID would know why is it there + the toll you pay in terms of performance is usually negligible and won't affect the overall performance a lot.

Key factor in deciding between GUID and int for example, is whether you need the universal uniqueness for your db entities. If not, you are equally fine with primitive types.

DrAlliteration
  • 3
  • 3
Siavash Rostami
  • 1,883
  • 4
  • 17
  • 31
  • 5
    "_Obviously the smaller the data type the faster it will be._". Obviously this is not generally true (aside from comparing between primitive data types with complex data types, maybe). The size of the key data type used does not determine the performance of the dictionary. Performance depends on how fast the hash value of the key values can be obtained/calculated and how evenly the hash values of the different keys used in the program distribute over the different dictionary buckets. –  Apr 27 '19 at 13:13
  • @elgonzo it's not significantly influential but an int key is faster than guid key. actually i've done some benchmarks on this exact matter in the past. i agree it's not the key factor in dictionary performance, difference is not really noticeable. – Siavash Rostami Apr 27 '19 at 13:19
  • 1
    (2/2) That said, in a scenario where many keys cluster in only a few dictionary buckets, the dictionary has to compare key values of keys in the same buckets, where performance will be determined by the complexity of the comparison (equality comparison) function... –  Apr 27 '19 at 13:20
  • Don't generalize like that just from experiences with using just only two different data types... –  Apr 27 '19 at 13:22
  • @elgonzo my benchmark was between GUID and the whole spectrum of primitive types, so it was actually a general benchmark :) – Siavash Rostami Apr 27 '19 at 13:24
  • No, it wasn't ;-) It was rather a very specifically narrow benchmark. Just native primitive data types against GUIDs... What about string vs. GUID? What about some other type X against some other type Y? No offence, but your benchmark wasn't general enough to justify such a sweeping general statment like "_Obviously the smaller the data type the faster it will be_" ;-) –  Apr 27 '19 at 13:26
  • @elgonzo ok, it was the primitive types plus string against standard GUID. well you can perform a comparison bet. custom complex types but they are merely special cases. by general i meant the common built-in types if you get my drift. – Siavash Rostami Apr 27 '19 at 13:29
  • "_But general i meant the common built-in types if you get my drift._" But that's not what you wrote in your answer there ;-) –  Apr 27 '19 at 13:30