Ctags: 병렬 ctags

안녕하세요,

내장된 병렬 구현이 흥미로울 수 있지만 다른 디렉토리에서 다른 ctag를 시작한 다음 생성된 파일을 병합하여 큰 코드베이스 업데이트를 병렬화하는 것이 이미 가능합니다(단 하나를 제외한 모든 파일에서 !로 시작하는 줄을 삭제하여 수행할 수 있습니다. 이후에 모든 파일에 대해 sort --merge 사용).

그러나 현대 기계가 I/O 바인딩될 것으로 예상하기 때문에 병렬화된 ctag에서 어떤 속도 향상도 얻을 수 있다고 확신하지 않습니다. 그래도 확인하려면 프로파일링해야 합니다.

@mawww https://github.com/ggreer/the_silver_searcher 가 동의하지 않을 것이라고 확신합니다 .wink :

여러 ctag를 실행하는 것은 표준 emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183에서 조정하기가 매우 어려울 것입니다.

@mawww https://github.com/ggreer/the_silver_searcher 가 동의하지 않을 것이라고 확신합니다 .wink :

좋은 지적.

여러 ctag를 실행하는 것은 표준 emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183에서 조정하기가 매우 어려울 것입니다.

쉘 스크립트 래퍼는 이미 먼 길을 갈 수 있지만, ctag에 직접 통합하는 것이 더 효율적일 수 있습니다.

@fommil 이 문제에 대한 그 사람의
그리고 자신의 테스트에서 너무 많은 작업자 스레드가 병렬 처리를 전혀 하지 않는 것보다 빠르게 악화되었음을 자신의 컴퓨터에서 어떻게 보여주었는지 주목하십시오. 귀엽긴 하지만 처리할 하드웨어, OS 및 데이터에 크게 의존할 가능성이 높기 때문에 "N 스레드를 사용하는 것이 내 테스트에서 더 잘 수행되는 것 같았습니다"보다 더 합리적일 것입니다.

또한 그것이 저에게 그다지 매력적이지 않은 또 다른 이유는 그것이 우리에게 많은 것을 줄 것이라고 믿지 않을 뿐만 아니라 많은 양의 오류가 발생하기 쉬운 작업이 될 것이라는 것입니다. 현재 CTags 코드 기반은 스레드를 구문 분석하는 병렬 태그를 지원하기 위한 형태가 전혀 없습니다. 상대적으로 쉽게 _할 수 있는_ 모든 것은 초기화/디렉토리 탐색과 _하나의 단일_ 파서 스레드입니다.
마지막으로 코드베이스(특히 파서)의 모든 곳에서 수행할 수 있는 보다 합리적인 최적화가 있다고 확신합니다.

확실히 멀티스레딩은 잘 사용하면 _할 수 있는_ _몇 가지_ 이점이 있지만 가장 흥미로운 개선 사항은 아닐 것입니다.

또한 그것이 저에게 그다지 매력적이지 않은 또 다른 이유는 […] 많은 양의 오류가 발생하기 쉬운 작업이 될 것이기 때문입니다. 현재 CTags 코드 기반은 스레드를 구문 분석하는 병렬 태그를 지원하기 위한 형태가 전혀 없습니다. 상대적으로 쉽게 _할 수 있는_ 모든 것은 초기화/디렉토리 탐색과 _하나의 단일_ 파서 스레드입니다.

BTW, 코드에서 이 영역을 개선하는 것이 좋은 생각이 아니라는 의미는 아닙니다. 제 생각에는 그렇게 생각합니다(특히 가능한 미래의 libctags의 경우). 성능이 목표라면 아마도 (현재) 노력할 가치가 없으며 집중해야 할 더 중요한 영역이 있음을 의미합니다.

BTW, 프로파일러를 시작하고 엄청난 양의 데이터를 프로파일링하는 것은 아마도 흥미로울 것입니다.

GNU 병렬이 도움이 될 수 있습니다.

언급 한 바와 같이 이전 , 최적화 독서는 ctags를에게 꽤 속도를 높일 수 있습니다.

I/O가 캐시에서 오는 경우 파서의 병렬 실행은 작업 속도를 상당히 높일 수 있습니다(그리고 이것은 종종 편집기에서 디렉토리에서 ctags를 실행하는 N번째 경우입니다).

@pragmaware IMO, 라이브러리는 포크해서는 안 됩니다.

일본어 텍스트를 읽는 경우 https://qiita.com/dalance/items/c76141a097e25fabefe8 기사를
(이 댓글을 작성하다가 ptags용 git 저장소를 찾았습니다(https://github.com/dalance/ptags). 페이지는 영어로 작성되어 있습니다.)

작성자가 개발한 ptags라는 도구를 보고합니다. 이 도구는 Rust로 작성되었으며 ctags를 래핑합니다.
입력 세트에 대해 병렬로 ctag를 실행합니다.
나는 그것의 내부를 약탈하지 않는다. 그러나 분명히 여러 ctag 프로세스를 실행합니다.

결과는 상당히 인상적입니다. 단일 처리보다 5배 빠릅니다. CPU 수는 기록되지 않습니다. 메모리 크기는 충분할 수 있습니다(=128GB). 작성자는 페이지 캐시를 뜨겁게 만들기 위해 동일한 입력 세트에 대해 10번 ptags를 실행합니다.

이러한 작업은 ptags와 같은 래퍼에서 수행되어야 하지만 이 훌륭한 결과를 무시하기 어렵습니다.
나는 빨리 해킹했다. https://github.com/masatake/ctags/tree/parallel
새로 도입된 옵션 --_parallel은 _parallel에서 여러 ctags 프로세스를 실행합니다.

작업자 프로세스의 수인 8은 하드 코딩되어 있습니다. 내 노트 PC에는 8개의 코어가 있습니다.
메모리는 32GB입니다. 대상 입력은 최신 Linux 커널 소스 트리입니다.
내 .ctags는 충분히 털이 있습니다.

결과는 거의 동일합니다. 2~3배 빠릅니다.

[yamato@master]~/var/ctags-github% cat run.sh
cat run.sh
for i in $(seq 1 5); do
    echo "#"
    echo "# TRAIL #$i"
    echo "#"
    echo "# parallel 8"
    time  ./ctags    --_parallel -R  ~/var/linux > /dev/null
    echo "# single"
    time  ./ctags -o - --sort=no -R  ~/var/linux > /dev/null
done
[yamato@master]~/var/ctags-github% bash run.sh 
bash run.sh 
#
# TRAIL #1
#
# parallel 8

real    0m29.073s
user    3m5.791s
sys 0m32.347s
# single

real    1m21.397s
user    1m14.601s
sys 0m6.521s
#
# TRAIL #2
#
# parallel 8

real    0m29.746s
user    3m4.601s
sys 0m32.175s
# single

real    1m26.660s
user    1m19.176s
sys 0m7.191s
#
# TRAIL #3
#
# parallel 8

real    0m28.290s
user    3m2.524s
sys 0m31.081s
# single

real    1m21.927s
user    1m14.775s
sys 0m6.896s
#
# TRAIL #4
#
# parallel 8

real    0m28.644s
user    3m3.839s
sys 0m31.756s
# single

real    1m13.319s
user    1m7.294s
sys 0m5.843s
#
# TRAIL #5
#
# parallel 8

real    0m29.274s
user    3m9.387s
sys 0m32.363s
# single

real    1m13.621s
user    1m7.487s
sys 0m5.941s
[yamato@master]~/var/ctags-github% 

(두 개의 태그 파일을 비교해봤습니다. 차이는 없습니다.)

만족과는 거리가 멀지만 시작하기에 좋은 곳입니다.

노동자들의 산출물을 모아야 하는지 말아야 하는지 궁금하다.

안녕하세요 @masatake 저는 작업할 계획이 없는 열린 티켓을 모두 닫으려고 합니다. 이 티켓 작업에 관심이 있으시면 텍스트를 새 티켓에 복사해 주시겠습니까?

나는 앞으로 이 항목에 대해 작업할 것입니다. 여기 토론의 기록이 나에게 가치가 있기 때문에 이 항목을 열어두고 싶습니다.

@masatake 여전히 새 티켓에서 이 티켓에 연결하고 전체 기록을 유지할 수 있습니다. 새 작업을 위해 "Issues" 탭을 정리하려고 하고 이 티켓과 같은 어수선한 내용이 방해가 되는 것을 원하지 않기 때문에 이것은 저에게 정말 도움이 될 것입니다.

@fommil , Universal Ctags 의 원동력인 모르겠습니다 . 버그(또는 GitHub 용어로 "문제")를 열면 이 버그가 프로젝트의 속성이 됩니다. 나는 당신이 그것을 해제하고 그것에 대한 이메일을 받지 않을 수 있다고 믿습니다.

재개장.

@dtikhonov @masatake 이 티켓을 https://github.com/issues 보기의 유일한 티켓입니다.

티켓이 닫혀 있지 않으면 이 보기에서 티켓을 제거할 수 없습니다. 구독을 취소하더라도.

사실, 티켓을 생성할 때 리포지토리 소유자가 이 제어 권한을 가질 줄은 몰랐습니다. 그렇지 않으면 그렇게 하지 않았을 것입니다.

이 작업을 하려면 새 티켓을 만들고 이 티켓을 참조하십시오. 모든 토론은 보존됩니다. 또는 https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839의 내용을 복사하여 새 티켓에 붙여넣으세요.

이것은 내가 많이 묻는 것이 아니라고 생각합니다.

복사-붙여넣기를 위한 임시 GitHub 계정을 만들 수 있습니까?
그래서 당신은 스스로 복사-붙여넣기를 할 수 있습니다.
그런 다음 계정을 제거할 수 있습니다.

물론, 이것이 이 문제를 해결할 수 있는 유일한 방법이라면 그렇게 할 수 있습니다.

완료! 이 티켓을 닫을 수 있게 해주셔서 감사합니다. 내 TODO 작업을 크게 정리합니다.