Hallvard B Furuseth wrote:
We can drop the new CRC code in back-ldif in favor of the stronger MD5 from liblutil. They have the same speed on my host: CRC is simpler, but memory-bound. CRC guarantees to catch certain transmission errors like a few wrong bits, but this comes at the expense of its quality as a general hash function. Or we could use a slower SHA function, but I figure MD5 is already stronger than we need.
I had considered MD5 before (especially since we already had code for it) but it was slower, and we're not looking for cryptographic assurances or hash distribution anyway. Basically all of these crypto hash functions are overkill, in terms of hash size and computation. We're only looking to detect casual misuse or corruption, not malicious deception.
I didn't really spend a lot of time comparing the two functions' speed. But even with the memory access bottleneck, I would guess that on a loaded system with many threads running, the algorithm with fewer instructions is the better choice. Have you measured the throughput when multiple threads are executing?
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/