Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Hash clash in polymorphic variants
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-14 (16:03)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] Re: Hash clash in polymorphic variants
Kuba Ober wrote:
> A trivial solution to that is to keep both, as obviously each time an 
> equivalent of dlopen() is made, everything has to be rehashed. gperf 
> is "slightly" memory-hungry, so surely it'd need to be something using a 
> different algorithm. I'm talking hypothetically, but I also think it's a 
> weird design decision to use those possibly-colliding hashes.

I agree that it's a bit weird - but the clashes are very rare (and the
function was designed to keep them rare for "normal" usage).

>  String sorting/comparison isn't exactly a CPU killer, so couldn't the
>  original names have been used instead?

String comparison is much slower than integer comparison... we're talking
about one CPU instruction compared to a for loop! Jon would never use them
again :o) Not to mention the storage overhead of keeping the tag names in
memory - not great if you've got long lists of `YetAnotherTag.