[Cdash] ITK appears in GDCM cdash
eric.noulard at gmail.com
Thu Sep 3 13:35:02 UTC 2009
2009/9/3 Amitha Perera <amitha.perera at kitware.com>:
> On Thu, Sep 3, 2009 at 8:43 AM, Julien Jomier<julien.jomier at kitware.com> wrote:
>> Sorry that's what I meant: could we find a hashing algorithm which return
>> value fits in one integer?. Also, what are the complexity of the different
>> hashing algorithms? in another word, which one will be fast enough with the
>> minimal chance of collisions?
> I'm pretty sure the SHA-1 and MD5 algorithms will prove to be fast
> enough for your needs. And I'm sure there are implementations of them
> in any language you want.
> Also, I suspect that
> SELECT * WHERE CRC=myCRC;
> will run pretty much just as fast as
> SELECT * WHERE HASH_INT1=myInt1 AND HASH_INT2=myInt2 ... AND HASH_INT4=myInt4;
> It's been a while since I did any serious SQL, but I think a SQL CHAR
> can represent any value between 0 and 255, so it may be just as easy
> to represent the hash as a CHAR(16) or what ever. And again, I'm
> pretty sure the SELECT statement would execute without any noticeable
> difference in speed.
Julien seems to think
that string comparison was slow (compared to int comparison)
>> "we will need to do a string matching in SQL and I'd like to
avoid this if we can for speed reasons"
However since as far as I understand you don't need cryptographic hash function
you may look into some non-cryptographic hash function
that has been designed to be fast, like that one
Seems to be used with MySQL too:
Note that FNV may not be the sole choice in this area.
Membre de l'April - « promouvoir et défendre le logiciel libre » -
More information about the CDash