From: Tao Klerks <tao@klerks.biz>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git <git@vger.kernel.org>,
Jeff Hostetler <jeffhost@microsoft.com>,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard?
Date: Thu, 24 Jun 2021 20:51:55 +0200 [thread overview]
Message-ID: <CAPMMpogek1N=5D8OVBLGXyWGgur4=-1Txever0P=86Lr7AEeKQ@mail.gmail.com> (raw)
In-Reply-To: <CAPMMpogjr43111HfPzk23c98JBaiEF2YA_OTkQVG1a63zyeiOw@mail.gmail.com>
Fwiw, I've now submitted a patch(set) that I believe addresses this
particular issue correctly:
https://lore.kernel.org/git/pull.986.git.1624559401.gitgitgadget@gmail.com/
Thanks,
Tao
On Mon, Jun 21, 2021 at 10:52 PM Tao Klerks <tao@klerks.biz> wrote:
>
> Hi Jeff, thanks for the update!
>
> On Mon, Jun 21, 2021 at 8:41 PM Jeff Hostetler <git@jeffhostetler.com> wrote:
> > We're currently looking at a problem that we believe is in the
> > untracked-cache code. This is causing some of our Scalar tests
> > to fail on Windows when the untracked-cache is turned on.
>
> For what it's worth, I just discovered an untracked cache bug this
> evening, although I doubt it's related to the one you mention - it's
> not very exciting:
>
> If you disable untracked cache (and write an index file), and then
> enable untracked cache and run status with "-uall" (writing a new
> index file), the untracked cache data written in the new index file is
> empty/invalid, and subsequent "git status" calls perform just the same
> as if untracked cache were disabled:
> ----
> # write an index without untracked cache
> git -c core.untrackedcache=false status
>
> # write another index with invalid/empty/bad untracked cache because
> "-uall" skipped its population/maintenance
> git -c core.untrackedcache=true status -uall # expected to be slow
>
> # run regular "git status" (with untracked cache) any number of times,
> but don't get the benefit (and you don't write a new index because
> nothing appears to have changed)
> git -c core.untrackedcache=true status # unexpectedly slow
> git -c core.untrackedcache=true status # unexpectedly slow
> git -c core.untrackedcache=true status # unexpectedly slow
> ---
> # TO FIX:
> # write a new index file without untracked cache
> git -c core.untrackedcache=false status
>
> # run regular "git status" (with untracked cache), does work and
> writes a new index file
> git -c core.untrackedcache=true status # slow as expected
>
> # run regular "git status" (with untracked cache) any number of times,
> is fast as expected
> git -c core.untrackedcache=true status # fast as expected
> git -c core.untrackedcache=true status # fast as expected
> git -c core.untrackedcache=true status # fast as expected
> ----
>
> I suspect this issue has bit me in the past when attempting to
> understand untracked cache behavior; it can be *very* confusing, if
> you're using tooling like "git extensions" that can, in the above
> flow, "poison" your untracked cache if it just happens to run a "git
> status -uall" in the background as you are testing.
>
> (I discovered this issue while trying to understand the weird &
> wonderful relationship between the repo-level untracked cache
> reference, the dir-level untracked cache reference, and the mechanisms
> that initialize a new one at dir.c#new_untracked_cache() and write the
> repo-level one (even if the dir-level reference was voided due to flag
> mismatch) at dir.c#write_untracked_extension())
>
> Should I be reporting this in some more "official" form somewhere? Is
> there a bug DB?
>
> Thanks,
> Tao
next prev parent reply other threads:[~2021-06-24 18:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 10:24 Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard? Tao Klerks
2021-06-11 9:49 ` Johannes Schindelin
2021-06-21 12:50 ` Tao Klerks
2021-06-21 18:41 ` Jeff Hostetler
2021-06-21 20:52 ` Tao Klerks
2021-06-24 18:51 ` Tao Klerks [this message]
2021-06-24 5:25 ` Tao Klerks
2021-06-24 13:10 ` Jeff Hostetler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPMMpogek1N=5D8OVBLGXyWGgur4=-1Txever0P=86Lr7AEeKQ@mail.gmail.com' \
--to=tao@klerks.biz \
--cc=Johannes.Schindelin@gmx.de \
--cc=dstolee@microsoft.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=jeffhost@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.