Отладка визуально с использованием >>,>,> |, ||, | <, <, <

Question

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

Что я действительно хотел бы, так это иметь функциональные возможности быстрой перемотки вперед, воспроизведения, паузы и перемотки назад в сочетании с визуальным представлением кода. Это означает, что я мог настроить код для работы в режиме быстрой перемотки вперед, пока я не перейду к графическому интерфейсу в критической точке. Затем я устанавливаю код для запуска в медленном режиме, в то время как я получаю некоторое визуальное представление того, какие строки выполняются (возможно, какое-то уменьшенное представление кода). Я мог бы, например, установить скорость выполнения примерно 0,0001x. Я полагаю, что таким образом я получу очень хорошую визуализацию того, находится ли проблема внутри определенного модуля или, возможно, в связи между модулями.

Это существует? Моя конкретная потребность в Python, но мне было бы интересно увидеть такую ​​функциональность на любом языке.

Answer 1

Функция «Быстрая пересылка к критической точке» уже существует в любом отладчике, она называется «точкой останова».Действительно, существуют отладчики, которые могут замедлять выполнение, но это не поможет вам отладить проблемы с производительностью, поскольку не замедляет работу компьютера.Процессор, диск и память все еще работают так же медленно, как и раньше, все, что происходит, - это то, что отладчик вставляет задержки между каждой строкой кода.Это означает, что каждая строка кода внезапно занимает более или менее одно и то же время, а это означает, что она скрывает любые следы проблемы производительности.

Единственный способ найти проблемы производительности - записать каждый выполненный вызов.в приложении и сколько времени это заняло.Это то, что делает профилировщик.Действительно, использование профилировщика сложно, но, вероятно, лучшего варианта нет.Теоретически вы можете записывать каждый вызов и время каждого вызова, а затем воспроизводить его назад и вперед с перемоткой назад, но это потребовало бы удивительное количество памяти, и это на самом деле не скажет вам ничего больше, чем делает профилировщик (на самом деле, он скажет вам меньше, поскольку пропустит некоторые типы проблем с производительностью).

С помощью профилировщика вы сможете выяснить, что занимает много времени.Обратите внимание, что это может быть связано с тем, что определенные вызовы функций занимают много времени, поскольку они выполняют много операций, или системные вызовы, которые занимают много времени, становятся чем-то медленным (сеть / диск).Или может быть, что очень быстрый вызов называется нагрузками и нагрузками раз.Профилировщик поможет вам понять это.Но это помогает, если вы можете включить профилировщик только в критической секции (уменьшает шум) и если вы можете запустить эту критическую секцию много раз (повышает точность).

Answer 2

Методы, которые вы описываете, и многие комментарии кажутся мне относительно слабыми вероятностными попытками понять влияние на производительность.Профилировщики работают очень хорошо для графических интерфейсов и других незанятых программ, хотя для их чтения требуется небольшая практика.Я думаю, что ваш лучший выбор там - учитесь использовать профилировщик лучше, вот для чего он.

Конкретное использование, которое вы описываете, будет просто прикреплять профилировщик, но пока не записывать.Перейдите GUI к рассматриваемому вопросу.Нажмите кнопку записи в профилировщике, выполните действие и остановите запись.Посмотреть результаты.Фикс.Сделай это снова.

Answer 3

Я предполагаю, что есть фаза выполнения приложения, которая занимает слишком много времени - то есть это заставляет вас ждать. Я предполагаю, что вы действительно хотите видеть, что вы можете изменить, чтобы сделать это быстрее.

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

Вот несколько способов, которыми ваша программа может тратить больше времени, чем необходимо.

• Ввод / вывод, о котором вы не знали и на самом деле не нуждались.
• Распределение и освобождение объектов очень часто.
• Быстрые уведомления о структурах данных.
• других слишком много, чтобы упоминать ...

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

Если программе требуется 5 секунд, а это может занять 1 секунду, то вероятность того, что вы увидите проблему при каждой паузе, составляет 4/5. Фактически, любой вызов функции, который вы видите в более чем одном образце стека, если вы можете избежать этого, даст вам значительное ускорение. И почти все возможные узкие места могут быть найдены таким образом.

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

Пример добавления: если вы берете 5 образцов стека и на 2 из них появляется строка кода, то она отвечает примерно за 2/5 = 40% времени, отдача или возьмите . Вы не знаете точный процент, и вам не нужно знать. (Технически, в среднем это (2 + 1) / (5 + 2) = 3/7 = 43%. Неплохо, и вы точно знаете, где это.)