Re: [PATCH 0/9] Prefix-compress on-disk index entries
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 4, 2012, 18:44 UTC
- Message-ID
- <7vpqbn8hgr.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CACsJy8A+cJtzKdqJSWbmjT1LgP10LB69-NHfOv8S6BusGcMeFw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 5 quoted lines
> On Wed, Apr 4, 2012 at 5:53 AM, Junio C Hamano <gitster@pobox.com> wrote: > ... > I wonder what causes user time drop from .29s to .13s here. I think > the main patch should increase computation, even only slightly, not > less.
The main patch reduced the amount of the data needs to be sent to the machinery to checksum and write to disk by about 45%, saving both I/O and computation.
This is a tangent, but I wonder why we are not using csum-file API to do this (I know the dircache code came first way before csum-file; I am wondering why we haven't rewritten the codepath using it later).
> Anything else you have in mind for v4? Any chance we can adopt crc32 > instead of sha-1?
I am not interested in sacrificing integrity over unproven/unmeasured performance "issues" on SHA-1, so I am not planning to experiment with such a change myself. The choice of hashing algorithm from my point of view is the least interesting part.