[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subprojects in project.el (Was: Eglot, project.el, and python virtua

From: Tim Cross
Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)
Date: Fri, 25 Nov 2022 09:46:12 +1100
User-agent: mu4e 1.9.3; emacs 29.0.50

João Távora <joaotavora@gmail.com> writes:

> On Thu, Nov 24, 2022 at 3:01 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>>  I'm imagining that traversing a directory tree with an arbitrary 
>>  predicate is going to be slow. If the predicate is limited somehow (e.g. 
>>  to a list of "markers" as base file name, or at least wildcards), 'git 
>>  ls-files' can probably handle this, with certain but bounded cost.

I've seen references to superior performance benefits of git ls-file a
couple of times in this thread, which has me a little confused.

There has been lots in other threads regarding the importance of not
relying on and not basing development on an underlying assumption
regarding the VCS being used. For example, I would expect project.el to
be completely neutral with respect to the VCS used in a project.

So how is git ls-file at all relevant when discussing performance
characteristics when identifying files in a project?

I also wonder if some of the performance concerns may be premature. I've
seen references to poor performance in projects with 400k or even 100k
files. What is the expected/acceptable performance for projects of that
size? How common are projects of that size? When considering
performance, are we not better off focusing on the common case rather
than extreme cases, leaving the extremes for once we have a known
problem we can then focus in on?   

reply via email to

[Prev in Thread] Current Thread [Next in Thread]