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

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

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

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

ОТВЕТЫ

Ответ 1

  • Заставьте это работать.
  • Если производительность сомнительна, профиль и определить проблему
  • Устранить проблему.
  • Повторите шаги 1-4, если необходимо
  • ???
  • Profit

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

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

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

Ответ 6

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

Махач ^^

Ответ 7

Ни одно качество (то есть легко читаемое), а производительность не является самым важным - CORRECTNESS is!

Ответ 8

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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