Планирование эффективности рано по сравнению с Преждевременной оптимизацией

Оптимизируйте при дизайне и уровне архитектуры вначале. Микрооптимизируйте на уровне реализации позже.

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

Концентрат на написании кода, которое делает точно, что это, как предполагается, делает, и только необходимое количество раз. Оптимизация чистого, изящного кода обычно проста.

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

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

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

Что-то большее чем это должно ожидать пока (a) не будет ясно, что улучшение производительности окупится и (b) Вы не знаете, где горячие точки.

При адаптации кавычки "это - тактика, если Вы побеждаете, и это обманывает, если бы Вы проигрываете", сказал бы я

Это "планирует эффективность", если это работало, и это - "преждевременная оптимизация", если это не сделало.

Мне нравится формулировка этого парня.

1. Оптимизация при помощи более разумного общего подхода.
2. Оптимизация путем создания кода менее странным.
3. Оптимизация путем создания кода более странным.

Первые два - Вы, указывают 2. Его 3 являются Вашим 1 и тем, который является корнем всего зла. И он прав, оптимизация, которая делает код "более странным", делает его более сложным и более трудным понять, приводя к большему количеству ошибок и головных болей обслуживания.

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

Я также имел бы: Используйте соответствующие и эффективные структуры данных от запуска. Это действительно покрывает широкий спектр вещей:

1. Знайте, как все стандартные контейнеры работают, к чему они способны и в чем они плохи. например, SortedDictionary быстр во вставке и поиске, но плох при удалении. LinkedList быстр, чтобы добавить и удалить, но плохой при поиске и так далее.
2. Знайте, где Ваши горлышки бутылки будут. Это будет CPU, диск, память, графика, IO, сети, и т.д. Знайте, как использовать каждого эффективно, каждая область требует различных шаблонов разработки. Это действительно зависит от приложения, разработанного также - что ядро является метрикой для концентрации на, для скорости отклика UI, для обработки данных хорошее кэширование диска.
3. Multhreading. Если приложение масштабируется к нескольким ядрам, нужно решить очень вначале в жизненном цикле разработки, если такая система необходима. Соединение болтом распараллеливающий на на более позднем этапе является намного более дорогостоящим.

Некоторые ответы, которые Вы будете знать на основе опыта, некоторые потребуют исследования, но это никогда не будет работа предположения.

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

Существует одна основная истина:

Вы не можете оптимизировать то, что Вы не можете протестировать

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

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

К сожалению, это - одни из тех дебатов, которые не имеют никакого реального закрытия.

Базы данных в особенности не легко осуществить рефакторинг и часто являются самым большим узким местом в системе из-за разработчиков, которые думают, что не должны заботиться о производительности, когда они разрабатывают. Это близоруко. Существует много известной оптимизации базы данных, которая будет почти все время быть быстрее. Не использовать их в Вашем дизайне и кодировании начальной буквы для предотвращения "преждевременной оптимизации" глупо. Например, курсор почти никогда не будет (если Вы не будете искать рабочие общие количества), работают лучше, чем основанный на наборе запрос в SQL-сервере. Записать курсор вместо основанного на наборе запроса не быстрее (после того как Вы понимаете основанные на наборе запросы), таким образом, нет никакой причины запуститься с основанного на курсоре кода. То же самое с полученными подзапросами недостатка таблиц. Почему пишут код, Вы знаете, что 90% времени будут медленнее, чем другой код, который занимает то же количество времени для записи?

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

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

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

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

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

1. Производительность
2. Пригодность для обслуживания
3. Устойчивость

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

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

Моя теория, "Напишите простой рабочий код, затем оптимизируйте, поскольку тестирование требует".