Не имеет смысла объединять их в такие серии. Вы хэшируете одно 32-битное пространство в другое 32-битное пространство.
В случае столкновения crc32 на первом шаге конечный результат все еще остается столкновением. Затем вы добавляете любые потенциальные коллизии на шаге adler32. Так что лучше не может быть, а может быть только таким же или хуже.
Чтобы уменьшить коллизии, вы можете попробовать что-то вроде использования двух хешей независимо для создания 64-битного выходного пространства:
adler32 (данные) << 32 | crc32 (данные) </p>
Есть ли значительная выгода от этого, я не уверен.
Обратите внимание, что исходный комментарий, на который вы ссылались, хешировался независимо:
Какой бы алгоритм вы не использовали
будет некоторый шанс ложного
позитивы. Тем не менее, вы можете уменьшить
эти шансы со значительным отрывом
используя два разных хэширования
алгоритмы. Если бы вы были рассчитать
и хранить как CRC32, так и
Alder32 для каждого URL, шансы
одновременное столкновение для обоих хэшей
для любой данной пары URL-адресов значительно
снижается.
Конечно, это означает, что хранить в два раза
много информации, которая является частью
ваша оригинальная проблема. Тем не менее, есть
это способ хранения обоих наборов хэша
данные такие, что это требует минимального
память (10 КБ или около того), давая
почти такая же производительность поиска (15
микросек / поиск по сравнению с 5
microsecs) как хэши Perl.