From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id BDA3C1F8C6 for ; Mon, 21 Jun 2021 20:52:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230329AbhFUUyb (ORCPT ); Mon, 21 Jun 2021 16:54:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229890AbhFUUya (ORCPT ); Mon, 21 Jun 2021 16:54:30 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8472CC061574 for ; Mon, 21 Jun 2021 13:52:14 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id d7so20876649edx.0 for ; Mon, 21 Jun 2021 13:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klerks-biz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ddksvuUAiy4GLY4fRqy9nrknJ6sgiwQQaOOihtxt7Ys=; b=t0DMV7uaQuirZkCv9VhxTksTf7RWZnj9qH2Tw9UMo4K+3hNBHvUfZcfG3+O/MeMRQc 0YpUltvfqNnD32cst0dQqvLGYbLBdqXxm6cTpT48hyWbw3VjreoJwj6cdJaIhmwnQkOR SVzJlSqCJVI38ecaNrI93k2OZW5XuBcewajt7r385acaR1/kJFRghCr0cquJetCbX3Qu FScfuF1hWN0QeyEbsrWO22qq164fTtlQ3OcRTAGRcLKXZ8kfue2hNQnVaMe9ugYptthv eaMC4K73nv92+6ps3rW1zZlgGTYSWjS6HevnncpKiGUTIVHn+lptZtccQZCli/Q59w3x ZnPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ddksvuUAiy4GLY4fRqy9nrknJ6sgiwQQaOOihtxt7Ys=; b=asxC1W5AYfCrgVUB5in9RgUQhSU3Dq/pi0OgY799CKr11PZL7WDvbORNwEA5kvxjaS qWR5D/PNdXXj+j3GN+wlpB/VBRK+7gIub3Mi2H2FwiQq/JfnfvXu/q+py2tiuwSxAksc SkgsOewIqb5FJP2H2ozMT0zoC7nQJMc7opzK+Mpu0uGNhzyPS+Ck3/q6Jy/N+P0psesO gTRt8kRlcapJ3jVNCxs2H6KDSbzdy2KilqrB0U+/t+NQwVbmK6gaRKvkxdW/zz/BcS3l RC+VEBzNItsgWUbA09WHil37SPBIamds1vtGJIDyvSNVRIFbugTOKRUpMR6XGTIhGWd9 PBjg== X-Gm-Message-State: AOAM532AVMBJedshAL63BCLfELishpCWcLIrDUzKVOVonVs1lWQUvl6u ZkP0z/rxQPcXQWk2wzdvXSGarr0ov2PcEncRIKX3sQ== X-Google-Smtp-Source: ABdhPJzHi1wjc7hS1R4KKXPLTT3rrxincC0Iim3lIjusRP4vsB8/9O7Fx7FeoRppO2BIOezUFlC5KZDAz5I5AjwtSmE= X-Received: by 2002:a05:6402:4cf:: with SMTP id n15mr391323edw.162.1624308733133; Mon, 21 Jun 2021 13:52:13 -0700 (PDT) MIME-Version: 1.0 References: <81153d02-8e7a-be59-e709-e90cd5906f3a@jeffhostetler.com> In-Reply-To: <81153d02-8e7a-be59-e709-e90cd5906f3a@jeffhostetler.com> From: Tao Klerks Date: Mon, 21 Jun 2021 22:52:02 +0200 Message-ID: Subject: Re: Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard? To: Jeff Hostetler Cc: Johannes Schindelin , git , Jeff Hostetler , Derrick Stolee Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Jeff, thanks for the update! On Mon, Jun 21, 2021 at 8:41 PM Jeff Hostetler 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