Что определяет производительность отладчика во время выполнения - PullRequest
10 голосов
/ 19 февраля 2012

Я попытался отладить Python 3 с помощью Wing IDE (v.4.1.3) и Komodo IDE (v.7.0.0). Как и ожидалось, отладчик добавляет много времени выполнения. Но что меня удивило, так это то, насколько разные отладчики могут быть между собой.

Вот время выполнения для той же программы. Никаких точек останова или чего-либо еще, просто обычный запуск без какой-либо реальной отладки:

  • выполняется интерпретатором Python: 26 секунд
  • выполняется отладчиком # 1: 137 с
  • выполняется отладчиком № 2: 1143 с

Я называю отладчики анонимными № 1 и № 2, чтобы это не стало непреднамеренной (и, возможно, ошибочной) рекламой одного из них.

Один из отладчиков действительно в 8 раз "быстрее"?

Или есть какой-то компромисс в дизайне, когда более быстрый отладчик отказывается от некоторых функций, точности, надежности или чего-то еще в обмен на большую скорость? Если это так, я бы хотел узнать эти подробности, особенно для Wing / Komodo или для отладчиков Python в целом.

Ответы [ 2 ]

14 голосов
/ 21 февраля 2012

Оптимизированный отладчик Python, как и любое другое программное обеспечение, может сильно отличаться по производительности (я автор PyDev, и я сделал отладчик PyDev, поэтому я могу комментировать его, но недругие, поэтому я просто объясню немного об оптимизации отладчика Python - поскольку я потратил много времени на оптимизацию отладчика PyDev - я не буду говорить о других реализациях, так как я не знаю, как онибыло сделано - за исключением pdb, но pdb на самом деле не является быстрой реализацией отладчика после того, как она достигает точки останова и вы проходите через нее, хотя она работает хорошо, выполняя неотслеживаемые вещи, пока вы фактически не выполните код, который начнет трассировкуваш код).

В частности, любой «наивный» отладчик может значительно замедлить вашу программу, просто включив трассировку Python в каждом кадре и проверив, есть ли совпадение точек останова для каждой выполняемой строки (примерно так работает pdb).: всякий раз, когда вы вводите контекст, он отслеживает его, и для каждой вызываемой строки он проверяет разрывoint соответствует этому, поэтому я полагаю, что любая реализация, которая рассчитывает на быструю реализацию, не может полагаться на нее).

Я знаю, что отладчик PyDev имеет несколько оптимизаций ... главная из них заключается в следующем: когдаотладчик входит в новый фрейм (то есть: функция), он проверит, есть ли «потенциальная» точка останова, которая может быть достигнута, и если нет, она даже не отследит эту функцию (с другой стороны, когда точка останова будет добавлена ​​позжепосле выполнения программы она должна будет переоценить все предыдущие предположения, поскольку любой текущий кадр может в конечном итоге пропустить точку останова).И если он определит, что какой-то кадр должен быть прослежен, он создаст новый экземпляр для этого кадра, который будет отвечать за кэширование всего, что связано с этим кадром (это действительно было возможно только в Python 2.5, поэтому при работе над Python 2.4и ранее, если не установлено расширение threadframe, отладчик будет пытаться эмулировать это, что значительно замедлит его на Python 2.4).

Кроме того, отладчик PyDev в настоящее время использует преимущества Cython, хотя этоограничивается только CPython ... Jython, IronPython и PyPy не используют его в своих интересах), поэтому многие оптимизации по-прежнему выполняются с учетом режима чистого Python (к счастью, Cython достаточно близок к Python, так что для внесения изменений требуется малоэто работает быстрее на CPython с Cython).

Некоторые связанные посты, касающиеся эволюции оптимизации отладчика 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

В любом случае, запуск с отладчиком на месте будетвсегда добавляйте некоторые накладные расходы (даже если они сильно оптимизированы, такие как отладчик PyDev), поэтому PyDev также предоставляет тот же подход, который может быть использован в pdb: добавьте точку останова в коде, и он начнет отслеживать только в этой точке (которая являетсяфункция удаленного отладчика PyDev): http://pydev.org/manual_adv_remote_debugger.html

И в зависимости от функций, которые вы хотите, чтобы отладчик поддерживал, он также может быть медленнее (например: когда вы включаете разрыв для пойманных исключений в PyDev, программа будетвыполняется медленнее, потому что для правильного разбиения потребуется отслеживать больше вещей).

2 голосов
/ 21 февраля 2012

Это все равно, что спросить, почему программа A быстрее, чем программа B. Причина может быть не только в области отладки.

Я бы предположил, что большинство графических отладчиков построены на вершине или интерфейсе к *Модуль 1003 * pdb , входящий в стандартную библиотеку python (хотя и не все).Различия в производительности в основном сводятся к деталям реализации и накладным расходам обновления GUI.Разница может быть такой же простой, как создание ненужных глубоких копий по сравнению с прямыми ссылками в некотором слое кода.

Если вы беспокоитесь о производительности отладчика, то вам следует придерживаться более быстрого графического отладчика, если он не удовлетворяет требованиям.какая-то функция вам нужна.Вы спрашиваете об отличительных чертах;так как это так, они оба, очевидно, в настоящее время удовлетворяют ваши потребности по функциям.

Если один отладчик теряет точность или жертвует надёжностью, я бы сразу же обдумал его.Я мог бы предположить, что более медленный вариант:

  • Выполнение дополнительной работы или ненужных проверок (если разработчик не доверяет другим частям кода или их слишком много слоевили избыточность архитектурно).

  • Использование некачественного или бесполезного представления в кеше или алгоритмическая настройка или оптимизация кода не настолько высоки, как у более быстрого отладчика.Правильный выбор структуры данных и алгоритмическая оптимизация могут составлять порядки величин.Используя низкоуровневую оптимизацию (например, ctypes, psyco, pyrex) и т. Д., Вы можете изменить разницу на другой порядок.Помните, что Python предоставляет вам гибкие и мощные контейнеры по умолчанию, за которые вы всегда «платите», даже если вам не нужны все их функции.

Я обнаружил, что WinPDB довольно легкий, и я обычно его использую, поскольку он не привязывает меня к IDE и довольно эффективно поддерживает удаленную отладку.,Вы также можете попробовать затмение с pydev .Еще один новый инструмент, с которым я только что начал играть - это Python Tools для Visual Studio , который выглядит очень многообещающе.Существует также список отладчиков Python на вики Python.Возможно, стоит попробовать другим.

Относительно того, почему один быстрее другого, существует множество возможных факторов.Если у вас есть доступ к источнику отладчика, вы можете профилировать сам отладчик для выявления узких мест производительности.Но если вам нужен быстрый отладчик, который обрабатывает все основные сценарии использования, попробуйте еще несколько и придерживайтесь самого быстрого, отвечающего вашим потребностям.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...