Что оптимизация в порядке, чтобы сделать сразу же?

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

Вещи искать:

• Математические формулы, а не повторение.
• Шаблоны, которые известны и зарегистрированы.
• Существующий код / компоненты

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

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

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

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

Из Википедии:

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

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

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

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

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

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

Документация

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

Инструментарии

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

Complilers

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

Система определенная оптимизация

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

Алгоритмы

Стремитесь сделать алгоритмы доступа O (1) или O (Журнал N). Стремитесь сделать повторение по списку не больше, чем O (N). Если Вы имеете дело с большими объемами данных, избегаете чего-то большего чем O (N^2), если это вообще возможно.

Приемы кода

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

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

Вместо:

for (int i = 0; i < myArray.Count; ++i)
{
    // Do something
}

Сделайте:

int elementCount = myArray.Count;
for (int i = 0; i < elementCount ; ++i)
{
    // Do something
}

Классический случай.

Конечно, необходимо знать, какой набор это (на самом деле, как свойство/метод Count реализовано). Может не обязательно быть costy.

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

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

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

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

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

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

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

Другой случай, который я имел, решал "интернировать" Строку в Java или нет. Выполнение так должно оставить свободное место, но по стоимости времени. В моем случае сбережения пространства не были огромны, и марш был ускорен, таким образом, я не сделал интернирования. Документирование его сообщает кому-то еще, чтобы не потрудиться интернировать его (или если они хотят видеть, делает ли более новая версия Java его быстрее затем, они могут попробовать).

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

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

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

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