Можно было использовать профилировщика, но почему не только останавливают программу? [закрытый]

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

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

я также использовал его для разыскивания узкого места в компиляторе, который я записал. Вы не хотели бы пытаться повредить такую программу вручную, потому что у Вас действительно нет способа знать, повреждаетесь ли Вы в пятне, где bottlenck, или только в пятне после узкого места, когда ОС позволяют войти назад для остановки его. Кроме того, что, если бы главное узкое место - что-то, которое Вы ничего не можете сделать о, но требуется избавиться от всех других largeish узких мест в системе? Как Вам располагают по приоритетам, на какие узкие места напасть сначала, когда у Вас нет хороших данных по тому, где они весь , и каков их относительное влияние каждый?

Я использовал этот метод для Commodore 64, ОСНОВНОЙ много лет назад. Удивительно, как хорошо это работает.

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

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

РЕДАКТИРОВАНИЕ 25.11.2008: хорошо, ответ Vineet наконец заставил меня видеть то, что проблема здесь. Лучше поздно, чем никогда.

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

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

более трудно в эти дни, что с поточной обработкой и asynchrony, но это то, как я программное обеспечение мелодии - путем нахождения ненужных циклов. Не путем наблюдения, как быстро это - я делаю это в конце.

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

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

• , Если инструкция я нахожусь на стеке вызовов для части P (I) того времени, удаляя его из программы, если Вы могли, сохранит точно так много. Если это не очевидно, уделите ему немного внимания.

, Если инструкция обнаруживается на M = 2 или больше образца из N, его P (I) является приблизительно M/N и является определенно значительным.

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

, Таким образом, процесс настройки производительности является простым вопросом собирания инструкций (главным образом инструкции по вызову функции), которые поднимают их головы путем поднимания на нескольких образцах стека вызовов. Те - высокие деревья в лесу.

Уведомление, о котором мы не должны заботиться о графе вызовов, или сколько времени функции берут, или сколько раз их называют, или рекурсия.

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

можно говорить о лесах и деревьях, но для любой проблемы производительности, которую можно решить путем изменения кода, необходимо изменить инструкции, конкретно инструкции с высоким P (I). Таким образом, необходимо знать, где те, предпочтительно не играя Sherlock Holmes. Выборка стека говорит Вам точно, где они.

Эту технику более трудно использовать в мультипотоке, событийно-ориентированном, или системы в производстве. Это - то, где профилировщики, если они сообщили бы о P (I), могли бы действительно помочь.

Они должны быть некоторыми тривиальными примерами, что Вы работаете с получить полезные результаты с Вашим методом. Я не могу думать о проекте, где профилирование было полезно (любым методом), который получит достойные результаты с Вашим "быстрым и эффективным" методом. Время, которое требуется, чтобы запустить и остановить некоторые приложения уже, помещает Ваше утверждение рассматриваемых "быстрых".

Снова, с нетривиальными программами метод, который Вы защищаете, бесполезен.

РЕДАКТИРОВАНИЕ: Относительно, "почему это не более известно"?

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

Это, кажется, довольно неточно с наборами небольшой выборки, и получить наборы большой выборки заняло бы много времени, которое будет лучше проведено с другими полезными операциями.

Что, если программа находится в производство и используемый одновременно путем оплаты клиентам или коллегам. Профилировщик позволяет Вам наблюдать, не вмешиваясь (так же, из-за курса, который это немного поразит также согласно Heisenberg принцип ).

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

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

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

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

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

С профилированием:

• можно тогда повторно выполнить сценарий после каждого изменения для определения степени повышения производительности / регрессия.

• можно представить код различных аппаратных конфигураций, чтобы определить, будут ли производственные аппаратные средства достаточными.

• можно представить код согласно сценариям загрузки и стресс-тестирования, чтобы определить, как объем информации влияет на производительность

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

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

Ваш подход допустим и является другим объектом, панель инструментов разработчика. Это просто перевешено путем профилирования.

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

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

причина, почему, нажимая кнопку паузы в режиме отладки, не может дать реальное изображение поведения приложения, то, потому что отладчики представляют дополнительный исполняемый код, который может замедлить определенные части приложения. Можно обратиться к сообщение в блоге Mike Stall на возможных причинах для замедления приложения в среде отладки. Сообщение проливает свет на определенные причины как слишком много точек останова, создания объектов исключения, неоптимизированный код и т.д. Часть о неоптимизированном коде важна - режим "отладки" приведет к большой оптимизации (обычно встраивание кода и переупорядочение) бросаемый из окна, чтобы позволить хосту отладки (процесс, выполняющий Ваш код) и IDE синхронизировать выполнение кода. Поэтому удар паузы неоднократно в режиме "отладки" мог бы быть плохой идеей.

Существует различие между вещами, которые программисты на самом деле делают, и вещи, которые они рекомендуют, другие делают.

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

, Но я действительно не сказал бы другим программистам делать это, потому что это будет брать меня слишком долго для объяснения всех протестов. Слишком легко сделать неточное заключение на основе этого метода, и существует много областей, где это просто не работает вообще. (например, тот метод не показывает кода, который инициирован вводом данных пользователем).

Поэтому точно так же, как использование детекторов лжи в суде или "goto" оператора, мы просто не рекомендуем сделать это, даже при том, что у них всех есть свое использование.

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

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

Выборочные профилировщики полезны только тогда, когда

1. вы отслеживаете среду выполнения с небольшим количеством потоков. Предпочтительно один.
2. Глубина стека вызовов каждого потока относительно мала (для уменьшения невероятных накладных расходов при сборе выборки).
3. Вас беспокоит только время настенных часов, а не другие счетчики или узкие места в ресурсах.
4. Вы не инструментировали код для целей управления и мониторинга (отсюда и запросы дампа стека).
5. Вы ошибочно полагаете, что удаление кадра стека является эффективной стратегией повышения производительности независимо от того, равны ли внутренние затраты (за исключением вызываемых) практически нулевыми или нет
6. Вы можете не беспокоиться о том, чтобы научиться применять инженерию производительности программного обеспечения в повседневной работе в своей работе
7. ....

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

Уловка состоит в том, чтобы хорошо знать свои инструменты и выбирать лучшее для работы.

Я удивлен религиозным тоном с обеих сторон.

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

Вот небольшая правдивая история. Приложение (своего рода задача пакетной обработки) нормально работало в производственной среде в течение шести месяцев, и внезапно операторы звонят разработчикам, потому что оно работает «слишком медленно». Они не позволят нам прикрепить профилировщик выборки в продакшн! Вам придется работать с уже установленными инструментами. Не останавливая производственный процесс, просто используя Process Explorer , (какие операторы уже установлены на машине), мы могли видеть снимок стека потока. Вы можете взглянуть на верхнюю часть стопки, закрыть ее с помощью клавиши ввода и получить еще один снимок еще одним щелчком мыши. Вы можете легко получать образец примерно раз в секунду.

Не требуется много времени, чтобы увидеть, находится ли вершина стека чаще всего в DLL клиентской библиотеки базы данных (ожидающей базы данных), или в другой системной DLL (ожидающей системной операции), или фактически в некоторой метод самого приложения. В этом случае, если я правильно помню, мы быстро заметили, что в 8 случаях из 10 приложение находилось в вызове системного файла DLL для чтения или записи сетевого файла. Несомненно, недавние «обновления» изменили характеристики производительности файлового ресурса. Без быстрого и грязного и (санкционированного системным администратором) подхода к просмотру того, что приложение делает в производственной среде , мы потратили бы гораздо больше времени на попытки измерить проблему, чем на ее исправление.

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

Но когда электричество отключилось (так сказать) и разрядились батареи, это ' Хорошо знать, как пользоваться этой ручной отверткой.

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