Re: Review of current github code [Re: [GSoC] Designing a faster index format - Progress report week 6]

Thomas Rast [off-list ref] 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.