[Top][All Lists]

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

Re: A project-files implementation for Git projects

From: Tassilo Horn
Subject: Re: A project-files implementation for Git projects
Date: Fri, 04 Oct 2019 09:47:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

Hi Dmitry,

>> I just tried with the gcc repository with its about 100000 files.
>> Here it was about equal with ~30secs for both git and find.  The git
>> ls-files invocation on the command line with output piped to
>> /dev/null is done in one tenth of a second.
>> Oh, when dropping the `expand-file-name' call we're doing on every
>> file, it's ten times faster (~3secs).
> Nice observation, thanks. It's a significant per-item cost, so no
> surprise projects with lots of files are (were) doing worse than
> 'find'.
> I've changed it to 'concat' now which isn't free, but much faster.

Yes, that's much better/faster.  But shouldn't we use

  (let ((default-directory (file-name-as-directory dir))

in order to ensure that default-directory always has a trailing / and
concat DTRT?

By the way, in my major use-case for `project-files' (a source to raven)
I want the files to be relative to the given directory.  So I'm calling
`file-relative-name' on every file in the result.  It would be cool if
there was a way to return the file names relative to the given directory
(which wouldn't make much sense if multiple dirs are given, though).

> I wish someone did some benchmarking with Hg projects.
> mozilla-central (~200000 files) is still slower on my machine with Hg
> than with 'find'.

I'll do.


reply via email to

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