Open rgeary1 opened 11 years ago
Do you have benchmarks showing how much faster it is? I believe it's at least significantly longer, which is a minus.
The flaw was that it's possible to engineer collisions as far as I know, which isn't a problem for ninja's use case.
I don't have any numbers other than the performance quoted in the link (which is actually from an old version of the algorithm). I can implement it, shouldn't be hard.
@jhasse Help Wanted?
I wouldn't be able to review it, sry.
I meant, add the label to the issue on github so people understand that the maintainers of ninja won't work on this themselves.
If the label was "we won't work on this", I would add it. But "help wanted" sounds like "if you write a PR we will be happy to review and merge it" to me. But I wouldn't have the time to review a PR for this, so I don't want to give people wrong impressions.
If you're not going to accept a PR for an improvement (which, as you point out, implies that someone needs to review it), then close the damn bug. It's 6 years old. Just having the bug open actively indicates that the project considers it something worthy of action.
Closing would be the wrong message IMHO. Tags like "low priority" or "backlog" might be fitting.
Ninja computes the command line hash with MurmurHash2 (from the comments). There is a newer, faster MurmurHash algorithm, MurmurHash3 https://code.google.com/p/smhasher/wiki/MurmurHash3
Based on the quoted performance stats, MurmurHash3_x64_128 should take 66% of the time of MurmurHash2. Also MurmurHash2 had a flaw in the algorithm.