꽤 오랫동안 zsh를 사용하여 폴더에 대한 자동 완성 작업을 수행할 때 성능 문제가 발생했습니다. 마지막으로 문제의 원인과 해결 방법을 이해하는 데 시간을 투자했습니다. 아쉽게도 '무엇을'에서 멈춰야 하고, '어떻게 고치느냐'는 여전히 물음표입니다.
추적이 활성화된(및 추적이 비활성화된 .zshrc.local
) 디버그에서 zsh를 실행할 때 명확하게 볼 수 있습니다.
TAB을 두 번 누르고 실행하면 다음과 같은 결과가 $ cd ~/Documents/<TAB>
나타납니다.
....
+_cd:88> eval 'dir=( ~Documents/ )'
+(eval):1> dir=( '~Documents/' )
....
최신 응답 시간은 약 3초입니다.
cd a/<TAB>
이는 폴더 자동 완성( , cd a/b/<TAB>
, ... ) 의 모든 수준에서 발생합니다 cd <TAB>
.
설정을 시도해 보았습니다 set -o magicequalsubst
.
답변1
_cd
현재 버전의 완성 함수 88번째 줄zsh
cdablevars
이 옵션이 활성화된 경우에만 접근할 수 있는 섹션 에 있습니다 .
이 옵션이 활성화되면 사용자의 홈 디렉터리나 저장소 경로로 이동 cd username
합니다 (해당 사용자의 /var이 존재하고 cd var
현재 디렉터리에 / 디렉터리 가 없는 경우). 즉, 디렉터리(내부 또는 내부)로 존재하지 않는 경우처럼 동작합니다.cd
username
$var
username
var
$cdpath
cd foo
cd ~foo
foo
.
$cdpath
cd
이제 / 에 대한 작업이 완료되었습니다 pushd
. _cd
가능한 완성 목록과 Documents/
지금까지 입력한 내용을 작성할 때 폴더의 하위 디렉터리 목록을 제공해야 하며 Documents
, 활성화했으므로 cdablevars
사용자의 홈 디렉터리 또는 사용자의 홈 디렉터리에 대한 하위 디렉터리 목록을 제공해야 합니다. 변수 Documents
에 저장된 디렉터리입니다 $Documents
(있는 경우).
그렇기 때문에 그렇게 하는 것입니다 eval 'dirs=( ~Documents )'
.
이제 캐싱(LDAP, NIS+...)이 없는 대규모 네트워크 사용자 데이터베이스가 있는 시스템을 사용하는 경우 확장이 느릴 수 있습니다. zsh는 해시 테이블을 사용하고 사용자의 홈 디렉토리를 검색하기 위해 호출하므로 수백만 개의 변수가 있더라도 빨라야 하는 zsh
변수 목록을 살펴보게 됩니다 . 이는 케이스 부분에서 느릴 수 있습니다. 어느 쪽이 동일한 전화를 걸어야 하는지 확인해 볼 수 있습니다 .Documents
getpwnam("Documents")
Documents
id Documents
getpwnam()
나는 개인적으로 이 옵션을 피하고 싶습니다. cdablevars
언젠가는 확실히 당신에게 나쁜 놀라움을 안겨줄 것이기 때문입니다. 당신은 항상 그것을 cd ~user
하거나 하지 않을 수 있으며, 인수로 제공된 디렉토리가 아닌 다른 것으로 정말로 들어가고 싶을 때 명시적으로 요청하는 것이 더 낫다는 것을 cd ~var
알았습니다 .cd
cdablevars
기본적으로 이 작업을 수행하는 zsh
데 영감을 받아 1990년 첫 번째 버전에 이미 존재했습니다 . 내 생각에는 tcsh
그것은 역사적 유물로 간주되어야 한다 ~var
.cdablevars
속도 저하 문제를 해결하는 방법에 대해서는 getpwnam()
이름 서비스 데이터베이스 조정을 고려할 수 있습니다. 예를 들어, 사용하는 경우 설정을 늘려 sssd
백엔드를 다시 쿼리하기 전에 entry_negative_timeout
존재하지 않는 사용자 정보를 캐시하는 기간을 결정할 수 있습니다. Documents
사용자 데이터베이스 쿼리의 경우 3초가 너무 긴 것 같습니다. 이는 구성 문제가 있거나 공급자 서버를 사용할 수 없고 대체 메커니즘(있는 경우)이 최적으로 구성되지 않았음을 나타냅니다.