Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el

[Juri Linkov <juri@linkov.net>]

> On 03.01.2019 0:53, Juri Linkov wrote:
>> On the very old computer from the year 2010, but the most interesting are relative times:
>>
>> (benchmark 10 '(project-find-regexp "xyz1"))
>> => 7s
>> (benchmark 10 '(project-files-pipe-grep "xyz1"))
>> => 17s
>
> This is too bad. But did you use project-files-pipe-grep from
> 446bcaed37b66ec112aaec7a7960e20b969c8012 or
> from c708231803712bd37154c140afdfd8468cac603e?

I tried with the latest c708231803 (at least ‘vc-log-mergebase’ shows
that it's the latest), but optimized:

      (dolist (f files)
        (process-send-string process f)
        (process-send-string process "\0"))

was replaced with

      (process-send-string process (mapconcat #'identity files "\0"))

with no performance impact.

Trying 446bcaed37 has no difference either.

>> (benchmark 10 '(project-files (project-current t)))
>> => 11s
>
> This is weird. I can understand that listing all files can be slower on an
> old, HDD-based computer. But both project-find-regexp and project-files use
> 'find ... -path], and the former even adds Grep on top of it. Why is the
> "simpler" operation slower?

Are you sure that project-find-regexp uses ‘find ... -path’?

I see that slowness is because of many ‘-path’ filters used in project-files.

>> (benchmark 10 '(shell-command-to-string "find ... \\( -path ... \\) -prune -o  -type f -print0"))
>> => 11s
>>
>> (benchmark 10 '(shell-command-to-string "git ls-files"))
>> => 0.07s
>
> Could you try making a full project-files implementation on top of it?
> I wonder how much slower it will be.
>
> At least test (split-string (shell-command-to-string "git ls-files -z") "\0" t)

Using this instead of ‘(project-files (project-current t))’:

(benchmark 10 '(project-files-pipe-grep "xyz1"))
=> 3s