Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Tamir Duberstein <tamird@gmail.com>
Cc: git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
	"Patrick Steinhardt" <ps@pks.im>, "Jeff King" <peff@peff.net>
Subject: Re: [PATCH v3] ls-files: filter pathspec before lstat
Date: Mon, 15 Jun 2026 08:27:30 -0700	[thread overview]
Message-ID: <xmqq4ij3ddst.fsf@gitster.g> (raw)
In-Reply-To: <20260611-ls-files-pathspec-lstat-v3-1-f967e1a00c13@gmail.com> (Tamir Duberstein's message of "Thu, 11 Jun 2026 21:31:51 -0700")

Tamir Duberstein <tamird@gmail.com> writes:

> Prefilter only a single pathspec item, bounding the added work for each
> index entry. Applying match_pathspec() to multiple arguments can cost
> more than the lstat() calls it avoids. In a synthetic repository with
> 10,000 clean files, passing every path to ls-files --modified increased
> runtime from 112.5 ms to 494.1 ms when the prefilter was unconditional.

I still think the choice of special casing a pathspec with a single
element is a lot harder to justify and invite people to start
complaining "why one and not three?" than not special casing any
(which makes the code simpler as well), as long as it is documented
clearly, like the above paragraph, why the performance
characteristics are so much different when pathspec has more than
one elments, the users and future developers can take it from there.

So let me mark the topic for 'next' now.

Thanks.


      reply	other threads:[~2026-06-15 15:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  2:37 [PATCH v2] ls-files: filter pathspec before lstat Tamir Duberstein
2026-06-09  3:26 ` Junio C Hamano
2026-06-09  3:38   ` Tamir Duberstein
2026-06-09  3:42   ` Junio C Hamano
2026-06-09  3:48     ` Tamir Duberstein
2026-06-09 10:41 ` Jeff King
2026-06-09 23:15   ` Tamir Duberstein
2026-06-11  8:41     ` Jeff King
2026-06-11 15:17       ` Tamir Duberstein
2026-06-11 17:38       ` Junio C Hamano
2026-06-12  4:31 ` [PATCH v3] " Tamir Duberstein
2026-06-15 15:27   ` Junio C Hamano [this message]

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=xmqq4ij3ddst.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=tamird@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox