Теория и практика Java: Управление производительностью - есть ли у вас план?

Знать, когда оптимизировать, важнее, чем знать, как оптимизировать

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

Брайан Гетц, главный консультант, Quiotix

Брайан Гетц (Brian Goetz) - консультант по ПО и последние 15 лет работал профессиональными разработчиком ПО. Сейчас он является главным консультантом в фирме Quiotix, занимающейся разработкой ПО и консалтингом и находящейся в Лос-Альтос, Калифорния. Следите за публикациями Брайана в популярных промышленных изданиях. Вы можете связаться с Брайаном по адресу brian@quiotix.com



05.03.2007

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

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

Проблема? Что за проблема?

Как вы вообще узнаёте, что у вас проблема с производительностью? Для большинства команд разработчиков (перефразируя определение непристойности, данное судьёй Верховного суда США Поттером Стюартом), ответ таков: мы узнаём, что у нас возникла проблема, только когда видим её. И это самая суть проблемы - задачи производительности, показатели и измерения не рассматриваются до тех пор, пока не становится слишком поздно.

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

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

Обе стратегии имеют общую проблему - они не рассматривают управление производительностью как неотъемлемую часть процесса разработки.

Неправильная стратегия производительности A: Полное игнорирование производительности

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

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

Неправильная стратегия производительности Б: Оптимизация по ходу работы

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

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

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


Сделайте управление производительностью частью вашего процесса разработки

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

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

Семь раз отмерь, один раз отрежь

Измерение - это критический элемент управления производительностью. Думаете, данное исправление заставит код быстрее работать? Будьте готовы доказать это. Используйте свои инструменты измерения производительности, чтобы протестировать производительность до и после исправления. Что если замеры не показывают улучшения? Тогда будьте готовы аннулировать исправление. Зачем рисковать, нарушая работающий код, если вы не можете измерить выгоду?

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

Задачу поняли?

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

Особенно важно определить задачи производительности, когда параметры производительности задаются извне, либо заказчиком, либо другим отделом внутри компании. Когда кто-то говорит вам ускорить работу программу, вам следует для начала спросить: "Как сильно я должен её ускорить?" Иначе вы можете затратить при настройке больше ресурсов, чем необходимо, и всё же заказчик останется недоволен. Можно сильно разочароваться, если приложив существенные усилия для того, чтобы ускорить работу программы на 30 процентов, услышать в ответ следующее: "Хм, я надеялся на ускорение в 50 процентов".


Резюме

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=199883
ArticleTitle=Теория и практика Java: Управление производительностью - есть ли у вас план?
publish-date=03052007