В какой момент вы должны начать думать о производительности?

Поскольку я создаю приложения, я постоянно спрашиваю, является ли это наилучшим способом выполнения или реализации определенной функциональности. Часто я буду публиковать вопросы о stackoverflow или другом форуме, желая получить отзывы только для того, чтобы получать комментарии о том, как не «ставить корзину перед лошадью» в отношении производительности. Неужели большинство программистов не думают о производительности до тех пор, пока приложение не будет завершено или производительность абсолютно неприемлема? Я имею в виду, что я понимаю, что среды разработки отличаются от производственных сред и что вам не следует полностью полагаться на результаты вашего портативного компьютера разработчика ... но существуют практики и методы, которые обеспечивают более высокую производительность, чем другие.

Это плохая практика, чтобы учитывать производительность на протяжении всего процесса разработки? Должен ли я отодвинуть эти соображения, пока производительность на самом деле не снижается?

Обновить

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

Отсрочка из соображений производительности иногда основана на неправильном применении фразы:

Преждевременная оптимизация - корень всего зла.

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

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

Есть ряд вещей, которые вы можете сделать во время разработки, чтобы добиться хорошей производительности, без эзотерической (и преждевременной) оптимизации:

1. Используйте разумную, хорошо продуманную архитектуру.
2. Используйте структуры данных правильно.
3. Используйте технологии (библиотеки, фреймворки), которые работают адекватно.

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

Вот о чем НЕ ОЧЕНЬ думать:

• Является ли ++iбыстрее i++?
• Является ли switchбыстрее if?
• Должен ли я inlineмои функции?
• Виртуальные функции работают медленно?
• Является ли C ++ / Java / C # быстрее / медленнее, чем другие?
• бла, бла, ...

Вот о чем думать:

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

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

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

Нет, вы должны думать о производительности (особенно при проектировании баз данных) с самого начала. Люди, которые думают, что любая оптимизация - это преждевременная оптимизация, нанесли большой вред нашей отрасли. Цитата изначально была предназначена для того, чтобы люди не смотрели на микрооптимизации до того, как возникла проблема. Это не было предназначено, чтобы не делать никакой оптимизации вообще. Например, в базе данных есть много известных технических работ, которые работают плохо. Избегать этого в дизайне - это часть того, что вам нужно сделать. Реорганизовать базу данных с 100 000 000 записей очень сложно, потому что она была разработана с использованием неэффективных методов, и мы больше не можем избежать этой проблемы, покупая более качественное оборудование.

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

80% производительности - выбор правильного алгоритма и структуры данных для рассматриваемой проблемы; плохо оптимизированная быстрая сортировка все еще идет в ногу с высоко оптимизированной пузырьковой сортировкой в ​​среднем случае (в худшем случае это ничья).

То, что все в SO пытаются сбить с толку, - это мышление «что быстрее, ++ p или p ++», когда люди настолько увлекаются перехитриванием компилятора, что теряют отслеживание более крупной проблемы, в результате чего код становится хрупким, ошибка - ошибочно , а лучше всего, не намного быстрее, чем было бы более простое решение. Я имел дело с такого рода кодом из первых рук; один пример был настолько хрупким, что мы не смогли внести никаких изменений, не сломав его полностью.

¹ Где «правильность» означает «выполнение спецификации», что не является синонимом «без ошибок».

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

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

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

Чтобы придумать эти метрики, вам нужно понять, что должна делать ваша система. Например, требуются ли абсолютные показатели производительности (отклик в течение времени X) или измерения пропускной способности (X откликов за время Y)? Оптимизация пропускной способности и абсолютного времени требует разных подходов, и если вы не знаете, что действительно важно, вы можете оптимизировать неправильный путь.

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

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

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

Требования Документация сэкономит вам сотни часов времени, которые в противном случае были бы потрачены на ненужные процессы.

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

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

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

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

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

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

Это гораздо лучший подход с точки зрения ремонтопригодности.

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

Действительно хорошая текстовая статья о производительности: The Computer Performance Shell Game .

Компьютерная игра-оболочка производительности, также известная как «найти узкое место», всегда проводится между этими четырьмя ресурсами:

• Процессор
• диск
• сеть
• Память

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

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

• У тебя много памяти? - вы получите лучшую производительность со структурой данных «все в памяти», но если вам не хватит памяти, это снизит вашу производительность.
• Вам нужно упорство? База данных обеспечивает целостность, но медленнее, чем указанная выше структура данных «все в памяти». МНОГО медленнее.
• Можете ли вы кешировать результаты? Лак может помочь с этим! http://www.varnish-cache.org/

У этого списка нет конца.

Что вы можете сделать, так это написать «простейшую вещь, которая могла бы работать» из знаний, которыми вы в настоящее время обладаете, и сделать это модульным образом, чтобы вы могли легко реорганизоваться, когда знаете больше. Обратите внимание, что «самая простая» вещь не обязательно простая!

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

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

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

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

НТН

По-разному. Полезно иметь в виду правило 80/20: большая часть (скажем, 80%) кода в приложении никогда не будет выполняться достаточно часто, чтобы иметь какие-либо заметные различия в производительности. Вам нужно сосредоточиться на оставшихся 20%, когда приложение должно тратить около 80% своего времени выполнения.

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

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

Это зависит от того, на какой стадии развития вы находитесь

1) Если вы создаете функциональность своего программного обеспечения, продолжайте его и убедитесь, что оно работает нормально (т.е. желательно и эффективно).

2) Как только строительные блоки будут интегрированы, вы получите подсказку об использовании ресурсов, и у вас есть место для оптимизации.

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

Важно то, какие действия вы предпримете на основе всего этого мышления. Мысли дешевы, но действия могут нарушить код и уложиться в сроки.

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

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

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

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

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

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

ИМХО, важно думать о производительности, прежде чем внедрять систему, а думать только о. Вам следует проанализировать приложение и выяснить возможные потенциальные узкие места в производительности.

Затем внедрите систему как можно проще. Если проблемы с производительностью возникают, то оптимизируйте.

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

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

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

Вы также можете получить эффективные привычки, но они будут зависеть от языка. В C ++, например, "++ i;" как отдельное выражение или выражение всегда, по крайней мере, так же хорошо, как «i ++;», и потенциально может быть гораздо более эффективным. Тем не менее, в большинстве случаев вы должны писать чистый код и доверять компилятору. Привыкание беспокоиться о микроэффективности почти наверняка вызовет у вас больше проблем, чем решит. Для настольных приложений, либо компилятор, по крайней мере, такой же умный, как i >> 1и другие i / 2, или лучший способ повысить производительность - это получить лучший компилятор, так что не беспокойтесь об этом.

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

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

Когда я должен начать думать об этом? Сколько усилий я должен приложить к этому? Это зависит от масштаба Кокберна проекта. (Другими словами, каков риск отсутствия хороших результатов?)

Изучите основы заранее (см. Ответ Роберта Харви ). Чтобы применять ориентированное на производительность мышление на различных этапах разработки программного обеспечения, разработчик должен знать это изнутри, чтобы эти дополнительные соображения не мешали мыслительному процессу. (Другими словами, начните думать о производительности до того, как проект задуман.)

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

Затем, в зависимости от характера вашего проекта и его масштаба Кокберна:

• Быстрое прототипирование, или «ударить код, как будто завтра не будет», или внутренняя разработка с низким уровнем влияния на бизнес: просто ведите статистику. Не думайте о производительности еще. Реализуйте функцию самым простым способом. Придерживайтесь первого алгоритма, который приходит вам на ум.

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

• Настольные приложения, которые требуют последовательного, всестороннего подхода к производительности. Это не должно быть высоко оптимизировано; однако должно быть как можно меньше «зависаний» (невосприимчивости).

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

• Высокопроизводительные вычисления, требующие максимальной производительности оборудования.

  • Назначьте кого-то в вашей команде, чтобы он отвечал за анализ и представление статистики производительности.
  • Создавайте теории о характеристиках производительности, проверяйте с помощью экспериментов и сравнивайте со своими прогнозами из упрощенных моделей Comp Sci.
  *

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

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

Я всегда полагаюсь на простую формулу:

1. Сделай так, чтоб это работало
2. Сделать это правильно
3. Сделай это быстро

... в этой последовательности.

Согласно с2 , эта формулировка относится к Кент Бек .