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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

Махач ^^

Answer 6

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

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

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

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

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