Если что-то делает программу с одним потоком, скажем, в 10 раз дольше, вы можете запустить профайлер. Вы также можете просто остановить его с помощью кнопки "пауза", и вы точно увидите, что он делает.
Даже если он на 10% медленнее, чем он должен быть, если вы остановите его больше раз, в скором времени вы увидите, что он многократно делает ненужную вещь. Обычно проблема заключается в вызове функции где-то в середине стека, который действительно не нужен. Это не мешает проблеме, но она действительно находит ее.
Изменить: возражения в основном предполагают, что вы принимаете только один образец. Если вы серьезно, возьмите 10. Любая строка кода, вызывающая некоторый процент потерь, например 40%, будет отображаться в стеке на этой фракции выборок в среднем. Узкие места (в однопоточном коде) не могут скрыть от него.
EDIT: Чтобы показать, что я имею в виду, многие возражения имеют форму "недостаточно образцов, поэтому то, что вы видите, может быть полностью ложным" - смутные представления о шансе. Но если что-то из узнаваемого описания, а не только в рутине или рутинной активности, действует в течение 30% времени, то вероятность увидеть его на любом данном образце составляет 30%.
Тогда предположим, что взято всего 10 выборок. Количество раз, когда проблема будет видна в 10 образцах, следует биномиальное распределение, а вероятность увидеть ее 0 раз - 0,028. Вероятность увидеть его 1 раз .121. В 2 раза вероятность равна 0,233, а в 3 раза - 0,267, после чего она падает. Поскольку вероятность увидеть его менее двух раз составляет 0,28 + 0,121 = 0,13, это означает, что вероятность увидеть его два или более раз составляет 1 -.139 =.861. Общее правило заключается в том, что если вы видите что-то, что вы можете исправить на двух или более образцах, это стоит исправить.
В этом случае вероятность увидеть его в 10 образцах составляет 86%. Если вы в 14%, которые этого не видят, просто делайте больше образцов, пока не сделаете это. (Если количество образцов увеличено до 20, вероятность увидеть его два или более раз увеличивается до более чем 99%.) Таким образом, он не был точно измерен, но он был точно найден, и важно понять, что это может легко быть тем, что не удалось найти профайлеру, например, что-то, связанное с состоянием данных, а не с программным счетчиком.
На серверах Java всегда был аккуратный трюк, чтобы сделать 2-3 быстрых Ctrl - Breaks s подряд и получить 2-3 потоковых потока всех запущенных потоков. Просто посмотрите, где все потоки "есть" могут очень быстро определить, где ваши проблемы с производительностью.
Этот метод может выявить больше проблем с производительностью за 2 минуты, чем любая другая техника, о которой я знаю.
Потому что иногда это работает, и иногда это дает вам совершенно неправильные ответы. У профайлера есть гораздо лучший отчет о поиске правильного ответа, и он обычно быстрее работает.
Выполнение этого вручную нельзя назвать "быстрым" или "эффективным", но есть несколько профилирующих инструментов, которые делают это автоматически; также известный как статистическое профилирование.
Выборка Callstack - очень полезный метод профилирования, особенно при просмотре большой сложной базы кода, которая может тратить свое время в любом количестве мест. Преимущество в этом состоит в том, что измерение использования ЦП по времени настенного времени, что имеет значение для интерактивности, и получение вызовов с каждым образцом позволяет понять, почему вызывается функция. Я использую его много, но я использую для него автоматизированные инструменты, такие как Luke Stackwalker и OProfile и различные вещи, поставляемые поставщиком оборудования.
Причина, по которой я предпочитаю автоматические инструменты для ручной выборки для работы, я делаю статистическая мощность. Схватить десять образцов вручную - это хорошо, когда у вас есть одна функция, занимающая 40% времени исполнения, потому что в среднем вы получите в ней четыре сэмпла и всегда по крайней мере один. Но вам нужно больше образцов, если у вас плоский профиль, с сотнями функций листа, ни один из которых не занимает более 1,5% времени выполнения.
Скажите, что у вас есть озеро со многими видами рыб. Если 40% рыбы в озере являются лососем (и 60% "все остальное" ), то вам нужно поймать только десять рыб, чтобы знать там много лосося в озере. Но если у вас есть сотни разных видов рыб, и каждый вид индивидуально не более 1%, вам нужно поймать гораздо больше десяти рыб, чтобы сказать "это озеро составляет 0,8% лосося и 0,6% форели."
Аналогично в играх, над которыми я работаю, есть несколько основных систем, каждый из которых вызывает десятки функций в сотнях разных сущностей, и все это происходит 60 раз в секунду. Некоторые временные последовательности этих функций объединяются в общие операции (например, malloc), но в большинстве случаев это не так, и в любом случае нет единого листа, который занимает более 1000 & mu; s на кадр.
Я могу посмотреть на функции соединительных линий и посмотреть, "мы тратим 10% нашего времени на столкновение", но это не очень полезно: мне нужно точно знать, где в столкновении, поэтому я знаю, какие функции сжать. Просто "делайте меньше столкновений" только добирается до вас, особенно когда это означает выбрасывание функций. Я бы предпочел знать, что "мы тратим в среднем 600 & mu; s/frame на пропуски кеша в узкой фазе octree, потому что магическая ракета движется так быстро и касается многих ячеек", потому что тогда я могу отследить точное исправление: либо лучшее дерево, либо более медленные ракеты.
Ручная выборка была бы хорошей, если бы был большой 20% -ный кусок, скажем, stricmp, но с нашими профилями это не так. Вместо этого у меня есть сотни функций, которые мне нужно получить, скажем, 0,6% кадра до 0,4% кадра. Мне нужно бриться 10 & mu; s с каждой функции 50 & mu; s, которая называется 300 раз в секунду. Чтобы получить такую точность, мне нужно больше образцов.
Но в глубине души то, что делает Luke Stackwalker, это то, что вы описываете: каждые миллисекунды или около того, он останавливает программу и записывает стоп-колл (включая точную инструкцию и номер строки IP). Некоторым программам просто нужно десятки тысяч образцов, которые будут полезны для профилирования.
(Мы говорили об этом раньше, конечно, но я подумал, что это хорошее место для подведения итогов дискуссии.)
Там есть разница между тем, что действительно делают программисты, и тем, что они рекомендуют другим.
Я знаю множество программистов (включая меня), которые на самом деле используют этот метод. Это действительно помогает найти наиболее очевидные проблемы с производительностью, но это быстро и грязно, и это работает.
Но я бы не сказал другим программистам, потому что мне потребовалось слишком много времени, чтобы объяснить все оговорки. Слишком легко сделать неточное заключение, основанное на этом методе, и есть много областей, где он просто не работает вообще. (например, этот метод не обнаруживает никакого кода, который запускается пользователем).
Точно так же, как использование детекторов лжи в суде или утверждение "goto", мы просто не рекомендуем вам это делать, даже если они все используют.
Меня удивляет религиозный тон с обеих сторон.
Профилирование отличное, и, конечно, оно более совершенное и точное, когда вы можете это сделать. Иногда вы не можете, и хорошо иметь надежную резервную копию. Техника паузы похожа на ручную отвертку, которую вы используете, когда ваш электроинструмент находится слишком далеко, или выходы из кабины.
Вот короткая история. Приложение (вид задачи пакетной обработки) работало отлично в производстве в течение шести месяцев, и внезапно операторы вызывают разработчиков, потому что они идут "слишком медленно". Они не собираются позволять нам прикреплять профилировщик пробоотбора в производстве! Вы должны работать с уже установленными инструментами. Не останавливая процесс производства, просто используя Process Explorer (какие операторы уже установили на машине), мы увидели моментальный снимок стека потоков. Вы можете заглянуть в верхнюю часть стека, отбросить его клавишей ввода и получить еще один снимок с помощью другого щелчка мыши. Вы можете легко получить образец каждую секунду или около того.
Не требуется много времени, чтобы увидеть, что верхняя часть стека чаще всего находится в библиотеке DLL базы данных базы данных (ожидающей в базе данных) или в другой системной DLL (ожидающей системной операции) или фактически в некоторых метод самого приложения. В этом случае, если я правильно помню, мы быстро заметили, что 8 раз из 10 приложение находилось в системном DLL файле, читающем или записывая сетевой файл. Конечно, недавние "обновления" изменили характеристики производительности файлового ресурса. Без быстрого и грязного и (с учетом системного администратора) подхода, чтобы посмотреть, что приложение делает на производстве, мы потратили бы гораздо больше времени на то, чтобы измерить проблему, а не исправлять проблему.
С другой стороны, когда требования к производительности выходят за рамки "достаточно хороши", чтобы действительно продвигать конверт, профайлер становится важным, так что вы можете попытаться сбрить циклы со всех ваших близких десятков или двадцати горячих точек. Даже если вы просто пытаетесь придерживаться умеренного требования к производительности, требуя проекта, когда вы можете получить нужные инструменты, которые помогут вам измерить и протестировать, а также интегрировать их в свой автоматический процесс тестирования, это может быть очень полезно.
Но когда питание отключено (так сказать) и батареи разряжены, хорошо знать, как использовать эту ручную отвертку.
Итак, прямой ответ: знайте, что вы можете узнать, останавливая программу, но не бойтесь и прецизионных инструментов. Самое главное знать, какие задания требуют для каких инструментов.
Если мы возьмем вопрос "Почему он не лучше известен?" то ответ будет субъективным. Предположительно, причина, по которой это не известно, заключается в том, что профилирование обеспечивает долгосрочное решение, а не текущее решение проблемы. Он не эффективен для многопоточных приложений и не эффективен для приложений, таких как игры, которые тратят значительную часть своего времени на рендеринг.
Кроме того, в однопоточных приложениях, если у вас есть метод, который вы ожидаете использовать в большинстве случаев, и вы хотите сократить время выполнения всех других методов, тогда будет сложнее определить, какие второстепенные методы сначала сосредоточьте свои усилия.
Ваш процесс профилирования - это приемлемый метод, который может и работает, но профилирование предоставляет вам дополнительную информацию и дает вам возможность показать более подробные улучшения производительности и регрессии.
Если у вас есть хорошо оформленный код, вы можете изучить больше, чем просто определенный метод; вы можете увидеть все методы.
С профилированием:
Затем вы можете повторно запустить свой сценарий после каждого изменения, чтобы определить степень улучшения/регрессии.
Вы можете профилировать код в разных конфигурациях оборудования, чтобы определить, будет ли ваше производственное оборудование достаточным.
Вы можете профилировать код в сценариях загрузки и стресс-тестирования, чтобы определить, как объем информации влияет на производительность.
Вы можете облегчить для младших разработчиков визуализацию воздействия их изменений на ваш код, потому что они могут повторно профилировать код через шесть месяцев, пока вы находитесь на пляже или в пабе, или оба, Beach-pub, ftw.
Профилирование получает больше веса, потому что корпоративный код должен всегда иметь некоторую степень профилирования из-за преимуществ, которые он дает организации за длительный период времени. Чем важнее код, тем больше профилирования и тестирования вы делаете.
Ваш подход действителен и является еще одним элементом инструментария разработчика. Это просто перевешивается профилированием.
Нажатие кнопки паузы во время выполнения программы в режиме "отладки" может не предоставлять нужные данные для выполнения любых оптимизаций производительности. Если говорить откровенно, это грубая форма профилирования.
Если вам нужно избегать использования профилировщика, лучше использовать логгер, а затем применить коэффициент замедления для "проверки", где возникает реальная проблема. Профилисты, однако, являются лучшими инструментами для проверки.
Причина, по которой нажатие кнопки паузы в режиме отладки, может не дать реальной картины поведения приложения, заключается в том, что отладчики вводят дополнительный исполняемый код, который может замедлить некоторые части приложения. О возможных причинах замедления приложения в среде отладки можно найти в сообщении блога Майка Столла. Сообщение проливает свет на определенные причины, такие как слишком много точек останова, создание объектов исключений, неоптимизированный код и т.д. Важна часть о неоптимизированном коде - режим "отладки" приведет к большому количеству оптимизаций (как правило, упорядочивание), выведенное из окна, чтобы включить хост отладки (процесс, выполняющий ваш код) и среду IDE, для синхронизации выполнения кода. Поэтому многократная пауза в режиме "отладки" может быть плохой идеей.
Профилирование пробоотбора полезно только тогда, когда
Это должны быть некоторые тривиальные примеры, с которыми вы работаете, чтобы получить полезные результаты с помощью вашего метода. Я не могу придумать проект, в котором профилирование было бы полезно (любым способом), которое получило бы достойные результаты с помощью вашего "быстрого и эффективного" метода. Время, необходимое для запуска и остановки некоторых приложений, уже ставит ваше утверждение о "быстром" вопросе.
Опять же, с нетривиальными программами метод, который вы защищаете, бесполезен.
EDIT: Что касается "почему не лучше известно"?
В моем опыте обзор кода избегает низкого качества кода и алгоритмов, и профилирование также найдет их. Если вы хотите продолжить свой метод, это здорово - но я думаю, что для большинства профессиональных сообществ это так далеко от списка вещей, чтобы попробовать, что он никогда не получит положительного подкрепления, как хорошее использование времени.
Похоже, что это довольно неточно с небольшими наборами образцов и для получения больших наборов образцов потребуется много времени, которое было бы лучше потрачено на другие полезные действия.
Снимки трассировки стека позволяют видеть только стробоскопические рентгенограммы вашего приложения. Вам может потребоваться больше накопленных знаний, которые может дать вам профилировщик.
Трюк хорошо знает ваши инструменты и выбирает лучшее для работы.
Что делать, если программа находится в production и используется одновременно, платя клиентам или коллегам. Профилировщик позволяет вам наблюдать, не мешая (как много, потому что, конечно, у него будет небольшой удар по принцип Гейзенберга).
Профилирование также может дать вам более богатые и подробные точные отчеты. Это будет быстрее в долгосрочной перспективе.
EDIT 2008/11/25: Хорошо, ответ Vineet наконец-то заставил меня понять, в чем проблема. Лучше поздно, чем никогда.
Как бы то ни было, на земле возникла идея, что проблемы производительности обнаруживаются путем измерения производительности. Это путаное средство с концами. Так или иначе, я избегал этого путем однократного выполнения всего программного обеспечения уже давно. Я не ругался, чтобы замедлить его до скорости человека. Я пытался понять, поступают ли они неправильно или нет. То, как быстро сделать программное обеспечение - найти и удалить ненужные операции.
В наши дни ни у кого нет терпения в отношении однократного шага, но самое лучшее - выбрать случайное количество циклов и спросить, каковы их причины. (То, что может сказать вам стек вызовов). Если у хорошего процента из них нет веских причин, вы можете что-то с этим сделать.
В наши дни все труднее, что с потоками и асинхронностью, но тем, как I настраивать программное обеспечение - путем поиска ненужных циклов. Не видя, как быстро это происходит - я делаю это в конце.
Вот почему выборка стека вызовов не может дать неправильный ответ и почему не так много примеров.
В течение интересующего периода времени, когда программа занимает больше времени, чем вы хотели бы, стек вызовов существует непрерывно, даже если вы не отбираете его.
Если инструкция отображается на M = 2 или более выборках, из N ее P (I) приблизительно равна M/N и определенно значительна.
Единственный способ, которым вы не можете видеть эту инструкцию, - это волшебное время для всех ваших образцов, когда команда не находится в стеке вызовов. Тот факт, что он присутствует на долю времени, является тем, что предоставляет его вашим зондам.
Таким образом, процесс настройки производительности - это простой способ выбора инструкций (в основном, инструкций по вызову функций), которые поднимают голову, путем включения нескольких образцов стека вызовов. Это высокие деревья в лесу.
Обратите внимание, что нам не нужно заботиться о графе вызовов, длительности выполнения функций или о том, сколько раз они вызываются или рекурсии.
Я против обфускации, а не профайлеров. Они дают вам много статистики, но большинство из них не дают P (I), и большинство пользователей не понимают, что это важно.
Вы можете говорить о лесах и деревьях, но для любой проблемы с производительностью, которую вы можете исправить, изменяя код, вам нужно изменить инструкции, в частности инструкции с высоким P (I). Поэтому вам нужно знать, где они, желательно, не играя Шерлока Холмса. Выборка стека говорит вам, где именно.
Этот метод сложнее использовать в многопоточных, управляемых событиями или в системах производства. То, что профайлеры, если они будут сообщать P (I), действительно может помочь.
Выполнение кода отлично подходит для просмотра подробных подробностей и алгоритмов устранения неполадок. Это похоже на то, что дерево действительно близко и следит за каждой веной коры и ветки индивидуально.
Профилирование позволяет увидеть общую картину и быстро определить проблемы - как сделать шаг назад и посмотреть на весь лес и заметить самые высокие деревья. Сортируя вызовы функций по длительности времени выполнения, вы можете быстро определить области, которые являются точками неисправности.
Я использовал этот метод для Commodore 64 BASIC много лет назад. Удивительно, как хорошо это работает.
Я обычно использовал его в программах реального времени, которые перекрывали их временные рамки. Вы не можете вручную остановить и перезапустить код, который должен выполняться 60 раз в секунду.
Я также использовал его для отслеживания узкого места в компиляторе, который я написал. Вы не хотели бы пытаться разбить такую программу вручную, потому что у вас действительно нет возможности узнать, ломаетесь ли вы на том месте, где находится бутылочка, или просто на месте после узкого места, когда ОС разрешено вернуться к остановить его. Кроме того, что, если основным узким местом является то, о чем вы ничего не можете сделать, но вы хотите избавиться от всех других крупных узких мест в системе? Как вы определяете, какие узкие места нужно атаковать в первую очередь, когда у вас нет хороших данных о том, где они все, и каково их относительное воздействие?
Чем больше ваша программа, тем полезнее будет профилировщик. Если вам нужно оптимизировать программу, содержащую тысячи условных ветвей, профилировщик может быть незаменимым. Подайте свою самую большую выборку тестовых данных, а затем импортируйте данные профилирования в Excel. Затем вы проверяете свои предположения о вероятных горячих точках против фактических данных. Всегда есть сюрпризы.