On Sat, Mar 9, 2013 at 2:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> strncmp provides length information, compared to strcmp, which could >> be taken advantage by the implementation. Even better, we could check >> if the lengths are equal before calling strncmp, eliminating a bit of >> strncmp calls. > > I think I am a bit slower than my usual self tonight, but I am > utterly confused by the above. > > strncmp() compares _only_ up to the first n bytes, so when you are > using it for equality, it is not "we could check length", but is "we > MUST check they match to the length of the shorter string", if you > want to obtain not just faster but correct result. > > Am I mistaken? Yeap, the description is a bit misleading. Although you could get away with length check by doing !strncmp(a, b, strlen(a)+1). > Even if you are using strcmp() that yields ordering not just > equality, it can return a correct result as soon as it hits the > first bytes that are different; I doubt using strncmp() contributes > to the performance very much. Comparing lengths before doing > byte-for-byte comparison could help because you can reject two > strings with different lengths without looking at them. > > At the same time, I wonder if we can take advantage of the fact that > these call sites only care about equality and not ordering. I tried to push it further and compare hash before do the actual string comparison. It slowed things down (hopefully because the cost of hashing, the same one from name-hash.c, not because I did it wrong). -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html