Производительность всегда важна?

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

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

Если вы, OTOH, пишете приложение, всегда есть момент, когда оно будет достаточно быстрым. Пользователи не будут ни осознавать, ни заботиться о том, отреагирует ли нажатая кнопка в течение 0,05 или 0,2 секунды - даже если это коэффициент 4.

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

Нет. «Достаточно быстро», как правило, достаточно.

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

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

Итак, я предполагаю, что это сводится к следующему:

Заметят ли пользователи улучшения? Как это улучшение соотносится с конкурирующими сайтами?

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

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

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

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

Производительность определенно всегда важна в определенном смысле - возможно, не в том, что вы имеете в виду: а именно на всех этапах развития.

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

Но это '

Правила оптимизации Джексона:

Правило 1. Не делайте этого.

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

—MA Jackson

Извлечено из 2-го издания Code Complete.

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

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

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

Если это веб-сайт, было бы разумно отметить размер и производительность вашей страницы с помощью Firebug + yslow и / или скорость страницы Google. Еще раз,

производительность важна только в той степени, в которой разработка улучшения производительности занимает меньше времени, чем общее количество времени, которое будет сэкономлено для пользователя (-ей).

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

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

Производительность! = Оптимизация.

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

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

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

Этот «корень всего зла» quote почти всегда неправильно используется и неверно понимается.

Чтобы ваше приложение работало хорошо, в большинстве случаев можно добиться только хорошего дизайна. Хороший дизайн! = Преждевременная оптимизация, и это ' Совершенно нелепо писать дерьмовый код и бросать работу над дизайном как «злую» трату. Я не говорю конкретно о вас ... но я вижу, что люди делают это очень часто.

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

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

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

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

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

Только не сходите с ума, делая ненужные вещи.

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

Только не сходите с ума, делая ненужные вещи.

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

Только не сходите с ума, делая ненужные вещи.

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

Только не сходите с ума, делая ненужные вещи.

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

Только не сходите с ума, делая ненужные вещи.

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

Чтобы дать обобщенный ответ на общий вопрос:

Сначала сделайте это работают , затем делают его правильным , затем делают его быстрым .

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

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

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

затем сделать это правильным , затем сделать его быстрым .

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

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

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

затем сделать это правильным , затем сделать его быстрым .

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

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

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

и сделать это правильно) всегда важно. Даже в этом случае его часто можно решить после других функций.

и сделать это правильно) всегда важно. Даже в этом случае его часто можно решить после других функций.

Нет. Производительность не важна.

Низкая производительность важна.