Отладка визуально с использованием >>, >, >|, ||, | <, <, <<
Отладка проблем с использованием стандартного отладчика практически безнадежна, поскольку уровень детализации слишком высок. Другие способы используют профилировщик, но они редко дают мне хорошую информацию, особенно когда речь идет о GUI и фоновых потоках, поскольку я никогда не знаю, действительно ли пользователь ждал компьютер или нет. Другой способ - просто использовать Control + C и посмотреть, где в коде он останавливается.
Что я действительно хотел бы, так это иметь функциональные возможности быстрой перемотки вперед, воспроизведения, паузы и перемотки назад в сочетании с визуальным представлением кода. Это означает, что я мог настроить код для работы в режиме быстрой перемотки вперед, пока я не перейду к графическому интерфейсу в критической точке. Затем я установил код для запуска в медленном режиме, в то время как я получаю некоторую визуальную репрезентацию того, какие строки выполняются (возможно, какое-то уменьшенное представление кода). Я мог бы, например, установить скорость выполнения примерно 0,0001x. Я полагаю, что таким образом я получу очень хорошую визуализацию того, находится ли проблема внутри определенного модуля или, возможно, в связи между модулями.
Это существует? Моя конкретная потребность в Python, но мне было бы интересно увидеть такую функциональность на любом языке.
3 ответа
Функция "Быстрая пересылка к критической точке" уже существует в любом отладчике, она называется "точкой останова". Действительно, существуют отладчики, которые могут замедлять выполнение, но это не поможет вам отладить проблемы с производительностью, поскольку не замедляет работу компьютера. Процессор, диск и память все еще работают так же медленно, как и раньше, все, что происходит, - это то, что отладчик вставляет задержки между каждой строкой кода. Это означает, что каждая строка кода внезапно занимает более или менее одно и то же время, а это означает, что она скрывает любые следы проблемы производительности.
Единственный способ найти проблемы с производительностью - записывать каждый вызов, сделанный в приложении, и сколько времени это заняло. Это то, что делает профилировщик. Действительно, использование профилировщика сложно, но, вероятно, лучшего варианта нет. Теоретически вы могли бы записывать каждый вызов и время каждого вызова, а затем воспроизводить его назад и вперед с перемоткой назад, но это потребовало бы удивительное количество памяти, и на самом деле это не скажет вам ничего больше, чем делает профилировщик (на самом деле, он скажет вам меньше, поскольку пропустит определенные типы проблем с производительностью).
Вы должны быть в состоянии, с помощью профилировщика, выяснить, что занимает много времени. Обратите внимание, что это может быть связано как с некоторыми вызовами функций, которые занимают много времени, так как они выполняют много операций, так и с системными вызовами, которые занимают много времени и превращаются в нечто (сеть / диск) медленное. Или может быть, что очень быстрый вызов называется нагрузками и нагрузками раз. Профилировщик поможет вам понять это. Но это помогает, если вы можете включить профилировщик только в критической секции (уменьшает шум) и если вы можете запустить эту критическую секцию много раз (повышает точность).
Я предполагаю, что есть фаза выполнения приложения, которая занимает слишком много времени - то есть это заставляет вас ждать. Я предполагаю, что вы действительно хотите, чтобы увидеть, что вы можете изменить, чтобы сделать это быстрее.
Техника, которая работает, является случайной паузой. Вы запускаете приложение в отладчике и в той части его выполнения, которая заставляет вас ждать, приостанавливать его и проверять стек вызовов. Сделайте это несколько раз.
Вот несколько способов, которыми ваша программа может тратить больше времени, чем необходимо.
- Ввод / вывод, о котором вы не знали и на самом деле не нуждались.
- Выделение и освобождение объектов очень часто.
- Быстрые уведомления о структурах данных.
- другие слишком многочисленны, чтобы упоминать...
Независимо от того, что это, когда это происходит, проверка стека вызовов покажет это. Как только вы знаете, что это такое, вы можете найти лучший способ сделать это, или, возможно, не делать это вообще.
Если программа занимает 5 секунд, а это может занять 1 секунду, то вероятность того, что вы увидите проблему при каждой паузе, составляет 4/5. Фактически, любой вызов функции, который вы видите в более чем одном образце стека, если вы можете избежать этого, даст вам значительное ускорение. И почти все возможные узкие места могут быть найдены таким образом.
Не думайте о таймингах функций или о том, сколько раз они вызывались. Ищите строки кода, которые часто появляются в стеке, которые вам не нужны.
Добавленный пример: если вы берете 5 образцов стека и на 2 из них появляется строка кода, то она отвечает примерно за 2/5 = 40% времени, отдача или взятие. Вы не знаете точный процент, и вам не нужно знать. (Технически, в среднем это (2+1)/(5+2) = 3/7 = 43%. Неплохо, и вы точно знаете, где это.)
Методы, которые вы описываете, и многие комментарии кажутся мне относительно слабыми вероятностными попытками понять влияние на производительность. Профилировщики работают очень хорошо для графических интерфейсов и других незанятых программ, хотя их чтение требует небольшой практики. Я думаю, что ваш лучший выбор там - учитесь использовать профилировщик лучше, вот для чего он.
Конкретное использование, которое вы описываете, будет просто прикреплять профилировщик, но пока не записывать. Перейдите GUI к рассматриваемому вопросу. Нажмите кнопку записи в профилировщике, выполните действие и остановите запись. Посмотреть результаты. Фикс. Сделай это снова.