Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > Thomas has again been busy hacking, and the reading side is now capable > of reading a v5 index into the (existing) array-of-cache_entry format. > It is actually already measurably faster than both v4 and v[23] on the > Webkit index: > > Test this tree > ----------------------------------------- > 0002.1: v[23]: ls-files 0.13(0.11+0.02) > 0002.4: v4: ls-files 0.11(0.08+0.02) > 0002.5: v5: ls-files 0.09(0.06+0.02) > > I made up a hacky perf script on the spot, it's pasted at the far end of > this email. It would most likely still be slower than v4 if we didn't > switch away from SHA1, though -- we haven't really spent much time > looking into the speed, except for one particular avoidance of name > copies that translated into a roughly 30% speedup. Do you mean by "switch away from SHA-1" that your suspicion is a large part of the speed-up may be coming from the fact that the index file as a whole is no longer hashed? As long as the new format allows us to notice corruption in the file to a similar degree of confidence by some other means, I personally do not see it as a regression in safety. We however eventually would need to hook the logic to check for index corruption into fsck. Actually adding such a code to fsck can and probably should remain outside the GSoC project, but please make sure you have necessary checksums in the format to allow us to do so in the future. Thanks. -- 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