파이썬 인터프리터가 시작하는 데 12 초 정도 걸리며,`import pyexpat`에서 모두 사용됩니다.

Question

Homebrew -installed Python을 내 Mac (OS X 10.13.1 실행)에 사용하고 있으며, 통역사가 시작하는 데 실망 할 정도로 오랜 시간이 걸린다는 사실을 알게되었습니다. 이 문제를 해결하려고 밖으로 설정에서

, 나는 time있는 간단한 검사를했다 : 12초 : 문제의 문제가 심각 밝혀

PIPER-ALPHA:~$ time bpython -c 'pass' 

real 0m12.141s 
user 0m1.662s 
sys  0m10.073s 

...!

그런 다음 문제의 원인이되는 파이썬 모듈에 이르기까지 CLI 도구의 타이밍을 항목 화하는 데 사용되는 gnomon - 을 사용했습니다.

이

PIPER-ALPHA:~$ PYTHONVERBOSE=1 bpython -c 'pass' 2>&1 | tee -a /tmp/bpython-startup-messages | gnomon 

... gnomon 출력이 자세한 파이썬 인터프리터의 출력에 의해 발행 된 각 행 걸리는 시간을 보여줍니다 :이 명령을 사용했다. 그것은 다음과 같습니다

... 난 실행을 거의 십이초했다 출력의 라인 강조 - 매일 다른 라인은 일반적으로 몇 나노초했다대로, 가장 긴 지금까지를, 또는에서 대부분 몇 초. 어쩌면.

보통 파이썬 확장팩을 만난다면, 필자는 파이썬 확장을 직접 컴파일하거나 소스 코드를 수정하여 필요에 따라 적절하게 문제를 해결할 것입니다. 그러나이 경우에는 더 큰 Python 표준 라이브러리 모듈의 일부인 c 확장 모듈을 다루고 있습니다.이 모듈은 모두 Homebrew 바이너리 패키지 (Homebrew argot의 "병"이라고 함)와 함께 제공됩니다. 이 버전의 Python.

다른 사람이 증명할 수있는 문제입니까? 특히 유사한 상황에서 파이썬을 실행할 때 다른 사람이 보는 문제입니까? 그리고 가장 중요한 것은 어떻게 해결할 수 있을까요? Homebrew를 사용하거나 사용하지 않고 Python 설치 전체를 다시 빌드해야합니까?

Answer 1

나는 이것을 알아 냈습니다. 대답은 동시에 밝게 빛나고 당혹 스럽습니다. 그리고 내 솔루션은 비슷한 상황에 직면했을 때 다른 사람들을 도울 수 있습니다.

간단히 말해서 : Python 인터프리터가 과도하게 많은 양의 Python 확장 모듈을 설치하여 발생하는 동안 경험했던 것보다 오래 걸리 듯 12s가 걸렸습니다. 이 아니고 파이썬 2.7의 번들 된 코드 xml.parsers.expat 모듈이나 C-API pyexpat 확장 모듈의 문제가 아닙니다.

위트 :이 모듈을 가리키는 직접적이고 직접적인 증거 인 것으로 보이는 gnomon 도구를 사용하면 문제가있는 코드를 어디에서 발견 할 수 있는지 내 결론에 오해가있었습니다.

내 질문을 게시 한 후, 나는 약간의 추가 법의학 적 파고를했다. 명령 줄 속도 검사를 호출하는 동안 인터프리터에 전달한 Python 코드를 변경하여 gnomon 보고서에 동일한 12 초가 걸리는 중지가 표시되지만 다른 import 문이 발생하는 것으로 나타났습니다. 또한 일부 명령 변종 (예 : pythonpy CLT를 사용하여 실행 된 명령 변종)은 정지 동작에 전혀 시달리지 않는 것으로 나타났습니다.

필자는 실수로 우연히 마주 쳤을 때 문제의 징후를 담당하는 코드 라인을 정확하게 지적 할 수있었습니다. 테스트를 실행하는 동안 매우 긴 중단이 덜 성가 셨고 컨트롤이 끝났습니다. C'ing 중반에 여러 번의 테스트가있었습니다. ,

... pkg_resources 모듈을 수입 할 때, sys.path에 이름이 확장 디렉토리의 각 안내 : 그 중단 테스트 실행은 KeyboardInterrupt 예외로 종료하고, 동반 스택 트레이스 출력 기능하는 것을 드래그 된 밝혀 각 익스텐션의 각 패키지를 열거 한 다음, 모든 패키지의 모든 관련 메타 데이터를 읽어 들인 다음 구문 분석합니다. pkg_resources (그 자체가 필수적인 setuptools 모듈의 일부 임)을 사용하면 시간이 많이 걸리는 작업 (최소한 특정 인터프리터 호출 수명 동안 캐시 됨)이 트리거됩니다. Python 설치 방법과 인터프리터 호출 방법에 따라 pkg_resources을 사용하도록 트리거하는 무언가를 끝내거나 끝내지 않을 수도 있지만 파이썬 확장 패키지에서 널리 사용되므로 기회가 충분합니다. 뭔가에 의해 유발 될 것입니다.

actual function responsible for the actual loop that actually enumerates the packages은 _initialize_master_working_set()입니다. 위의 스크린 샷에서 강조한 부분입니다. 이것은 나의 모든 KeyboardInterrupt stacktraces가 공개 한 것입니다. 거기에서 좌절 한 중단은 현재 존재하는 Cheese Shop 패키지 (랩탑을 업그레이드 한 후 무모한 것)의 수가 가파르게 선형 함수 였음을 즉시 알게되었습니다.

나는 즉각적으로 설치 한 확장의 대략 50 %를 pip-uninstall하고, 40 % 정도를 능동적으로 개발 한 파이썬의 대부분을 고립 된 virtualenv 프로젝트 디렉토리로 끌어 올렸다.

멋진 분석 도구를 사용하여 나를 오도하는 데 능숙 해졌고, 우연히 실제 솔루션을 찾았습니다. 내 자신의 부주의 한 부주의로 인한 문제입니다. 그럼에도 불구하고, 그것은 여전히 ​​다른 Python 개발자를 물려 줄 수 있고 따라서 쓰기 가치가있는 것입니다. 당신은이 문제에 대한 나의 단호한 모험과 진단에서 실제로 배울 수있게 초대 받았습니다!