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

Question

Считаете ли вы, что стоит отказаться от некоторых показателей качества кода и ремонтопригодности? Я помню пост Джеффа Этвуда, в котором говорилось, что оборудование дешево, а разработчики - нет. Я думаю, я бы хотел изменить это на «Аппаратное обеспечение дешево, времени нет».

Я заметил, что с проектом MVC, с которым я работал в последнее время, иногда я теряю DAYS, просто пытаясь выжать немного дополнительной производительности из своего приложения, и я начинаю думать, что это просто не стоит. Я только что столкнулся с проблемой разработки ASP.NET MVC-приложения. Я люблю IQueryable до смерти в том, что он позволяет мне добавить к запросу, чтобы я мог получить некоторый свободный код для его использования. Но возможность сделать что-то подобное, похоже, повышает ответственность над контроллером/BLL.

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

Answer 1

1. Сделать работу
2. Если производительность сомнительный, профиль и определить проблему
3. Устранить проблему.
4. Повторите шаги 1-4, если необходимо
5. ???
6. Profit

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

Ни качество (то есть легко читать), а производительность - самая важная - КОРРЕКЦИЯ - это!

Answer 6

Сэр Тони Хоар классно сказал: «Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - это корень всего зла».

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

• Вы не знаете проблема есть.
  Вы угадывание.

  не

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

Вы можете прокомментировать код.

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

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

Answer 9

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

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

Answer 10

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

Значок Big 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-нотации, и эти знания позволят сделать ваш код намного быстрее, чем секундное бритье от вашего кода, когда будут работать жесткие петли.

Махач ^^

Answer 11

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

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

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

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

Answer 12

Это одна из классических характеристик по сравнению с поддержкой. Я впервые столкнулся с этим компромиссом при написании структурированного кода COBOL (в начале 1980-х годов). Стало ясно, что, разделив все на многократно используемые модули, создано дополнительное управление указателем ветвей и стека, а на ранних компьютерах это ухудшило производительность. Ответ заключался в объединении функций вместе (и дублировании определенных функций), чтобы сократить операции переключения кода и манипуляции с указателями стека, которые использовались для вызова модулей. Это вызвало проблему поддержки.

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