디버거 런타임 성능을 결정하는 요소

Question

Wing IDE (v.4.1.3) 및 Komodo IDE (v.7.0.0)를 사용하여 Python 3 디버깅을 시도했습니다. 예상대로 디버거는 많은 런타임 오버 헤드를 추가합니다. 그러나 나에게 놀랐던 점은 디버거가 서로간에 얼마나 다른지를 알 수 있다는 것입니다.

다음은 동일한 프로그램의 실행 시간입니다. 없음 중단하거나 다른 것, 실제 디버깅하지 않고 단지 일반 실행 : 파이썬 인터프리터에 의해 실행

• : 26 초
디버거 번호에 의해 실행
• 1 : 137 초
• 디버거 번호로 실행 2 : 1143 초

디버거를 익명 # 1 및 # 2로 지칭하여이 중 하나에 대한 의도하지 않은 (그리고 잘못되었을 가능성이있는) 광고가 나오지 않도록합니다.

디버거 중 하나가 실제로 "빠른"속도의 8 배입니까?

또는 더 빠른 디버거가 더 빠른 속도의 대가로 일부 기능 또는 정밀도 또는 견고성 등을 포기할 수있는 몇 가지 설계 절충점이 있습니까? 그렇다면, 나는 Wing/Komodo를위한 것이 든, 일반적으로 파이썬 디버거를위한 것이 든 그 세부 사항을 알고 싶다.

Answer 1

최적화 된 파이썬 디버거를 수행하는 것은 다른 소프트웨어와 같습니다. 성능이 현저히 다를 수 있습니다 (필자는 PyDev 작성자이며 PyDev 디버거를 작성 했으므로 주석을 달 수 있습니다). 나머지는 파이썬 디버거를 최적화하는 방법에 대해 조금 설명하겠다. PyDev 디버거를 최적화하는 데 많은 시간을 투자 했으므로 어떻게 구현해야할지 모르겠다. pdb를 제외하고는 끝났지 만, pdb는 breakpoint에 도달 한 후 실제로 디버거를 구현 한 것이 아니며, 실제로 시작될 코드를 실행할 때까지 untraced를 실행하여 잘 작동하지만 코드 추적).

특히 '순진한'디버거는 각 프레임에서 파이썬 추적을 활성화하고 실행 된 각 줄마다 중단 점 일치가 있는지 확인하여 프로그램을 훨씬 느리게 만들 수 있습니다 (대략적인 방법은 pdb 작동 방식입니다. 컨텍스트를 입력 할 때마다 추적 할 것이고 각 줄마다 중단 점이 일치하는지 검사 할 것이므로 빨리 수행 할 것으로 예상되는 구현은 실제로 그 대상에 의존 할 수 없다고 생각합니다.

PyDev 디버거에는 몇 가지 최적화가 있습니다 ... 주요한 것은 다음과 같습니다 : 디버거가 새로운 프레임 (즉 : function)을 입력하면 거기에 부딪 힐 수있는 잠재적 인 중단 점이 있는지 확인합니다. 존재하지 않는다면 그 함수를 추적하지도 않습니다 (다른 한편으로, 프로그램이 실행 된 후에 나중에 중단 점이 추가 될 때, 현재의 모든 프레임이 끝날 수 있기 때문에 모든 이전 가정을 재평가해야합니다) 중단 점을 건너 뜁니다. 그리고 어떤 프레임을 추적해야한다고 판단하면 해당 프레임과 관련된 모든 것을 캐시 할 책임이있는 해당 프레임에 대한 새 인스턴스를 만듭니다 (파이썬 2.5에서만 가능했기 때문에 Python 2.4에서 작업 할 때 이전에는 threadframe 확장이 설치되어 있지 않으면 디버거가이를 에뮬레이트하려고 시도해 파이썬 2.4에서 상당히 느려질 것입니다.

또한 PyDev 디버거는 현재 CPython에만 제한되어 있지만 Cython을 사용합니다 ... 자이 썬, IronPython 및 PyPy는이를 활용하지 않습니다. 따라서 많은 최적화가 여전히 순수 Python 모드 (고맙게도 Cython은 Python에 충분히 가깝기 때문에 Cython으로 CPython에서 더 빠르게 작동하게하려면 약간의 변경이 필요하다). PyDev의 디버거 최적화 진화에 관한

일부 관련 게시물 : 어쨌든

http://pydev.blogspot.co.id/2017/03/pydev-560-released-faster-debugger.html

http://pydev.blogspot.co.id/2016/01/pydev-451-debug-faster.html

http://pydev.blogspot.com/2008/02/pydev-debugger-and-psyco-speedups.html

http://pydev.blogspot.com/2005/10/high-speed-debugger.html

, 항상 약간의 오버 헤드를 추가 할 것이다 장소에 디버거를 실행 (심지어 w PyDev 디버거와 같이 많이 최적화 된 암)이므로 PyDev는 pdb에서 사용할 수있는 것과 동일한 접근법을 제공합니다. 코드에 중단 점을 추가하면 PyDev의 원격 디버거 기능인 해당 지점에서만 추적을 시작합니다. : http://pydev.org/manual_adv_remote_debugger.html

디버거에서 지원할 기능에 따라 느려질 수도 있습니다 (예 :: PyDev에서 catch 된 예외에 대한 중단을 활성화하면 제대로 중단되기 위해 더 많은 것을 추적해야하므로 프로그램이 더 느리게 실행됩니다.

Answer 2

이것은 프로그램 A가 프로그램 B보다 빠른 이유를 묻는 것과 같습니다. 이유는 디버깅 도메인과 관련이 없을 수 있습니다.

나는 대부분의 그래픽 디버거가 파이썬 표준 라이브러리에서 제공되는 pdb 모듈의 상단 또는 프론트 엔드에 내장되어 있다고 생각합니다. 성능 차이는 대부분 구현 세부 사항 및 GUI 업데이트 오버 헤드로 요약됩니다. 차이점은 코드의 일부 계층에서 불필요한 딥 복사본을 직접 참조하는 것보다 간단 할 수 있습니다.

디버거 성능에 대해 염려가되는 경우 필요한 일부 기능을 충족시키지 않으면 빠른 그래픽 디버거를 사용해야합니다. 기능 차이점을 묻습니다. 이 경우 이후로, 그들은 현재 분명히 귀하의 요구 사항을 현명하게 처리하고 있습니다.

하나의 디버거가 정밀도를 잃어 버리거나 견고성을 희생하면 즉시 고려 대상에서 제외합니다. 추가 작업 또는 불필요한 검사를 (개발자가 코드의 다른 부분을 신뢰하지 않거나 너무 많은 레이어 또는 중복 구조적 자신의 경우) 이렇게

• : 나는 기회가 느린 일 중 하나입니다 추측 것.

• 일부 캐시 비우호적 인 또는 낭비적인 표현을 사용하거나 더 빠른 디버거만큼 알고리즘 적으로 코드를 조정하거나 최적화하지 않았습니다. 올바른 데이터 구조 선택 및 알고리즘 최적화를 통해 차이가 큰 순서를 만들 수 있습니다. 낮은 수준의 최적화 (ctypes, psyco, pyrex 등) 등을 사용하면 차이의 크기를 다른 순서로 만들 수 있습니다. 파이썬은 모든 기능이 필요 없더라도 항상 "지불"할 수있는 유연하고 강력한 기본 컨테이너를 제공한다는 것을 기억하십시오.

나는 WinPDB 상당히 경량이며,이 IDE에 나를 묶어 나던 이후, 나는 일반적으로 사용하는 하나이며, 매우 효율적으로 원격 디버깅을 지원하는 것으로 나타났습니다. pydev으로 일식을 사용해 볼 수도 있습니다. 방금 시작한 또 다른 새로운 기능은 매우 유망 해 보이는 Python Tools for Visual Studio입니다.파이썬 위키에는 list of python debuggers도 있습니다. 다른 사람들에게 시험해 볼 가치가 있을지 모릅니다.

하나가 다른 것보다 빠르다는 이유는 여러 가지 요인이 있습니다. 디버거 소스에 액세스 할 수 있으면 디버거 자체를 프로파일 링하여 성능 병목 현상을 식별 할 수 있습니다. 그러나 기본 사용 사례를 모두 처리하는 빠른 디버거를 원한다면 몇 가지 더 시도해보고 필요에 맞는 가장 빠른 방법을 고수하십시오.