Re: [PATCH v1] add: speed up cmd_add() by utilizing read_cache_preload()

From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ben Peart <peartben@gmail.com>,
	Ben Peart <benpeart@microsoft.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v1] add: speed up cmd_add() by utilizing read_cache_preload()
Date: Sat, 3 Nov 2018 05:47:33 +0100	[thread overview]
Message-ID: <CACsJy8AZ4kxrpttfsHOWKP=Xg3HaTLySy7sepC5691mGzfgO5g@mail.gmail.com> (raw)
In-Reply-To: <xmqqmuqrngfu.fsf@gitster-ct.c.googlers.com>

On Sat, Nov 3, 2018 at 1:38 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Fri, Nov 2, 2018 at 2:32 PM Ben Peart <peartben@gmail.com> wrote:
> >>
> >> From: Ben Peart <benpeart@microsoft.com>
> >>
> >> During an "add", a call is made to run_diff_files() which calls
> >> check_remove() for each index-entry.  The preload_index() code distributes
> >> some of the costs across multiple threads.
> >
> > Instead of doing this site by site. How about we make read_cache()
> > always do multithread preload?
>
> I suspect that it would be a huge performance killer.
>
> Many codepaths do not even want to know if the working tree files
> have been modified, even though they need to know what's in the
> index.  Think "git commit-tree", "git diff --cached", etc.

Ah. I keep forgetting read_cache_preload is loading the index _and_
refreshing. I thought the two had some different semantics but failed
to see it last time.
-- 
Duy