Re: performance problem: "git commit filename"

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2008, 19:39 UTC
Message-ID: <7vsl11plbe.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.00.0801130922030.2806@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 14 quoted lines

> On Sun, 13 Jan 2008, Junio C Hamano wrote:
>> 
>> The attached is a quick and dirty hack which may or may not
>> help.  It all looks sane, this also is some core code, and meant
>> only for discussion and not application.
>
> I don't think this will help.
>
> You never set CE_UPTODATE, except in the "fill_stat_cache_info()" 
> function, but that one will never be called for an old file that already 
> matched the stat.
>
> So at a minimum, you should also make ie_match_stat() set CE_UPTODATE if 
> it matches. Or something.

Unfortunately ie_match_stat() is too late. The caller is supposed to have already called lstat(2) and give the result to that function.

When refresh_cache_ent() finds the entry actually matched, we could mark the path with CE_UPTODATE. That would be a relatively contained and safe optimization that might help git-commit.

About the CE_NAMEMASK limitation (and currently we do not check it, so I think we would be screwed when a pathname that is longer than (CE_NAMEMASK+1) and still fits under PATH_MAX is given), I think we do not have to limit the maximum pathname length. Instead we can teach create_ce_flags() and ce_namelen() that a name longer than 2k (or 4k) has the NAMEMASK bits that are all 1 and ce->name[] must be counted if so (with an obvious optimization to start counting at byte position 2k or 4k in ce_namelen()).