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).
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4