Re: Git status extremely slow if any file is a multiple of 8GBi

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2022, 16:08 UTC
Message-ID: <xmqq4k25nuvj.fsf@gitster.g>
In-Reply-To: <xmqqczgtpfl5.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> The condition sd_size==0 is used as a signal for "no, we really need
> to compare the contents", and causes the contents to be hashed, and
> if the contents match the object name recorded in the index, the
> on-disk size is stored in sd_size and the entry is marked as
> CE_UPTODATE.  Alas, if the truncated st_size is 0, the resulting
> entry would have sd_size==0 again, so a workaround like what you
> outlined is needed.

This is of secondary importance, but the fact that Jason observed 8GBi files gets hashed over and over unnecessarily means that we would do the same for an empty file, opening, reading 0-bytes, hashing, and closing, without taking advantage of the fact that CE_UPTODATE bit says the file contents should be up-to-date with respect to the cached object name, doesn't it?

Or do we have "if st_size == 0 and sd_size == 0 then we know what it hashes to (i.e. EMPTY_BLOB_SHA*) and there is no need to do the usual open-read-hash-close dance" logic (I didn't check)?