completion: improve ls-files filter performance

From the output of ls-files, we remove all but the leftmost path component and then we eliminate duplicates. We do this in a while loop, which is a performance bottleneck when the number of iterations is large (e.g. for 60000 files in linux.git). $ COMP_WORDS=(git status -- ar) COMP_CWORD=3; time _git real 0m11.876s user 0m4.685s sys 0m6.808s Replacing the loop with the cut command improves performance significantly: $ COMP_WORDS=(git status -- ar) COMP_CWORD=3; time _git real 0m1.372s user 0m0.263s sys 0m0.167s The measurements were done with Msys2 bash, which is used by Git for Windows. When filtering the ls-files output we take care not to touch absolute paths. This is redundant, because ls-files will never output absolute paths. Remove the unnecessary operations. The issue was reported here: https://github.com/git-for-windows/git/issues/1533 Signed-off-by: Clemens Buchacher <drizzd@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Clemens Buchacher committed Apr 4, 2018 at 09:46 UTC 78a2d2123103f4524bfce30511e0a8b2d27d3502
1 file changed +1 -6
contrib/completion/git-completion.bash
+1 -6
@@ -388,12 +388,7 @@ __git_index_files ()
388 local root="${2-.}" file
389
390 __git_ls_files_helper "$root" "$1" |
391 - while read -r file; do
392 - case "$file" in
393 - ?*/*) echo "${file%%/*}" ;;
394 - *) echo "$file" ;;
395 - esac
396 - done | sort | uniq
391 + cut -f1 -d/ | sort | uniq
392 }
393
394 # Lists branches from the local repository.