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

Junio C Hamano [off-list ref] writes:

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)?