emacs-devel
[Top][All Lists]
Advanced

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

Re: Subprojects in project.el


From: Dmitry Gutov
Subject: Re: Subprojects in project.el
Date: Sat, 26 Nov 2022 00:33:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 25/11/22 21:56, João Távora wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:

Have you seen the code I posted? You'll notice that it doesn't do
any file system operations, it just does file name operations. And
those run in CPU/memory, not file system. So I cannot understand
your argument.  But I am happy to measure performance in different
scenarios, if you'd like to suggest a particularly problematic one.

I am commenting here on the idea to "Call all members of
project-find-functions". Members of project-find-functions do file
system operations.

And that's what your piece of code does (call all members):

I don't expect a large number of member functions to exist there,
though.  At most one function looks for .git and another looks for
markers like venv (or like in my example doesn't look for markers at
all).

Even when there are just 2 of them, it's 2x the initial delay, which can already be noticeable with Tramp. E.g. my ping to the "mainland" is around 100ms. And filesystem operations might take several roundtrips.

Further, the approach you mentioned (running all functions on the hook) implied that there will be more of them than one -- for different project kinds, simple markers or etc. Otherwise there would be no difference between doing that and just what we are doing now.

I really don't expect this to be a performance sink.  But since it's
easy to be wrong in these guesses, we can tweak the function that looks
for marker files .venv to only search if a current parent project is
there, just like my example.

If, on the other hand, the user's goal is to search for _both_ .git or
.venv (maybe she has some non-git venv projects) then we're just going
to have to look for two files and that's that.

I don't entirely understand the algorithm you're proposing here, but it sounds vaguely like what I'm writing now, so you might like the result.



reply via email to

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