Re: [PATCH v1 1/2] reset: don't compute unstaged changes after reset when --quiet
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Oct 18, 2018, 18:26 UTC
- Message-ID
- <CACsJy8CvvZcQdxnZbu-FZmVm7wtMDLocjiMVURhvJ=NtuYgi9w@mail.gmail.com>
- In-Reply-To
- <5b4d46c2-ac0b-8a44-5e99-b0926ea764d3@gmail.com>
On Thu, Oct 18, 2018 at 8:18 PM Ben Peart <peartben@gmail.com> wrote:
Show 15 quoted lines
> I actually started my effort to speed up reset by attempting to > multi-thread refresh_index(). You can see a work in progress at: > > https://github.com/benpeart/git/pull/new/refresh-index-multithread-gvfs > > The patch doesn't always work as it is still not thread safe. When it > works, it's great but I ran into to many difficulties trying to debug > the remaining threading issues (even adding print statements would > change the timing and the repro would disappear). It will take a lot of > code review to discover and fix the remaining non-thread safe code paths. > > In addition, the optimized code path that takes advantage of fsmonitor, > uses multiple threads, fscache, etc _already exists_ in preload_index(). > Trying to recreate all those optimizations in refresh_index() is (as I > discovered) a daunting task.
Why not make refresh_index() run preload_index() first (or the parallel lstat part to be precise), and only do the heavy content-based refresh in single thread mode?
-- Duy