[Mono-dev] Type.GUID patch

[Robert Jordan]

Hi Sebastien,

>>The hash appears to change with the assembly name and type name.
>>Renaming gt.cs will return another GUID as well as renaming
>>"App". Renaming gt.exe doesn't change the GUID.
>>Applying an AssemblyVersionAttribute will change the GUID,
>>so I'm pretty sure, that Type.AssemblyQualifiedName is taken
>>into account while generating the hash.
>>
>>The following algorithm computes the GUID from
>>Type.AssemblyQualifiedName using a MD5 hash: 
>>
>>Guid ComputeGuid (Type t)
>>{
>>     byte[] bytes = System.Text.Encoding.UTF8.
>>         GetBytes (t.AssemblyQualifiedName);
>>     using (System.Security.Cryptography.MD5 md5 =
>>            System.Security.Cryptography.MD5.Create ()) {
>>         return new Guid (md5.ComputeHash (bytes));
>>     }
>>}
>>
>>Is it a patch worth?
> 
> 
> I guess it depends on how it's gonna be used. This isn't the first time
> people talks about Type.Guid but I never seen any talk about _using_
> it ;-) at least not with Mono.
> 
> MD5 will give you a 128 bits digest value, which match the required Guid
> length, and recent problems related to MD5 are pretty much irrelevant to
> such usage. So it's probably (if everything is included in the qualified
> name) a correct implementation - functionality-wise.
> 
> But creating a using MD5 is kind of heavyweight - even more if a new
> instance is created each time. So anyone using this heavily will notice
> a big performance problem.

MSFT's implementation (actually an InternalCall) is 3 times slower
then the computation of an MD5 hash using an *unmanaged* implementation
of the MD5 algorithm. It's probably slower because it has to generate
properly formatted UUIDs which consists of only 122 random bits.
(see the 2nd link of Kornél's post).

Ok, I don't think it's worthwhile to provide an unmanaged InternalCall
for a property that obviously nobody uses.

Rob