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

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

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

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

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

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

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

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

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

эта цитата "корень всех зол" почти всегда используется неправильно и неправильно понята.

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

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

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

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

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

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

просто не сходите с ума, делая ненужные вещи.

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

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

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

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

первый сделать работа, затем сделать право, затем сделать быстро.

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

Это ставит более конструктивную перспективу на "преждевременная оптимизация является корнем всего зла".

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

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

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

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

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

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

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

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

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

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

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

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

Так что я думаю, что это ломается до это:

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

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

нет. Достаточно быстро, как правило, достаточно хорошо.

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

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

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

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

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

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

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

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

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