Производительность по сравнению с качеством кода

Сэр Tony Hoare заметно сказал, "Мы должны забыть о маленькой эффективности, сказать приблизительно 97% времени: преждевременная оптимизация является корнем всего зла".

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

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

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

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

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

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

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

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

В большой нотации O говорится что-то о том, сколько времени функция берет. Например. Список, работающий от 0 до 100, у Вас есть O (N). Неважно, как высокое количество, которое Вы считаете к нотации O, остается таким же. Эта функция имеет линейное время выполнения и не может быть улучшена никакими способами.

Теперь, если у Вас есть список, работающий от 0 до 100, и для каждого объекта в том списке Вы делаете другой список, работающий от 0 до 100, Вы получаете O (N^2), который является дважды работой и имеет намного худшее время выполнения, чем O (N).

При записи приложений, который должен иметь хорошую производительность, мы говорим о получении хорошего времени выполнения, записанного в нотации O. Использует ли окно <0,1 секунды или>, 1 секунда действительно не имеет значения, используют ли они те же алгоритмы.

Это означает, бритье секунд, которые Вы делаете, вероятно, не имеет другой нотации O, таким образом, Вы действительно не оптимизируете свой код всегда - Так для Вас, пишущий MVC в asp.net, я рекомендовал бы сфокусироваться на написании чистого и читаемого кода вместо этого :)

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

Makach^^

Все хорошие ответы. Выбором между скоростью и чистым кодом является ложная дихотомия.

Я не видел, что Вы работаете, но я наблюдал за другими, и это всегда - та же история:

"Это не достаточно быстро. Я думаю, что проблема находится в этих XXX кодах. Я думаю, что буду настраивать это и видеть, помогает ли это".

• Вы не знаете, что проблема там.
  Вы предполагаете.

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

Вы могли представить код.

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

Это обычно - удивление, что, возможно, не предположил.

Никакое качество (значение легкого читать), ни производительность не является самым важным - ПРАВИЛЬНОСТЬ!

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

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

Я не знаю, что соглашаюсь с 'аппаратными средствами, является более дешевым, чем разработчики' кавычка все же. Конечно, аппаратные средства могут помочь Вам масштабировать свое приложение и дать ему больше физической привлекательности производительности, но последняя вещь, которую Вы хотите сделать, полагаются на раскормленные аппаратные средства. Если Ваше программное обеспечение слишком сильно связывается к Вашим аппаратным средствам, Вы теряете большую гибкость с точки зрения перемещения в новые дата-центры, обновление серверов, и т.д.... и не наличие той гибкости могут быть очень дорогостоящими в долгосрочной перспективе. Скажите, что Вы решаете, что способ масштабировать Ваше приложение эффективно состоит в том, чтобы переместиться в инфраструктуру Amazon EC2. Если Ваше приложение требует 32 ГБ RAM на каждом сервере, Вы собираетесь найти, что перемещение как это могло бы потребовать переписывания.

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

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

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

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

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

Что касается решения проблем производительности, в большинстве случаев, я нашел, что проблемы производительности или связанный database/IO или a, но (утечка памяти). Как другие предположили, профилирование является способом пойти, хотя это может все еще быть хитро для разыскивания многих ошибок.

Что касается аппаратной проблемы, аппаратные средства ослабляют, но не избавляют от необходимости оптимизированный код. Более быстрые аппаратные средства действительно просто позволяют нам использовать меньше, чем оптимальные языки и делать действительно хороший материал GUI.

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

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