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

Чтение этот вопрос Я нашел это как (отметьте кавычки) "код", чтобы решить проблему (кстати, это perl).

100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*

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

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

ОТВЕТЫ

Ответ 1

Мой процесс для ситуаций, в которых, я думаю, производительность может быть проблемой:

  • Заставьте это работать.
  • Проясните.
  • Проверьте производительность.
  • Если есть существенные проблемы с производительностью: рефакторинг для скорости.

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

Ответ 2

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

Ответ 3

Я всегда начинаю с самой читаемой версии, о которой я могу думать. Если производительность является проблемой, я рефакторинг. Если читаемая версия затрудняет обобщение, я рефакторинг.

Ключ должен иметь хорошие тесты, так что рефакторинг прост.

Я рассматриваю читаемость как самую важную проблему в коде # 1, хотя правильная работа - вторая секунда.

Ответ 5

Мой любимый ответ на этот вопрос:

  • Заставьте это работать.
  • Сделайте это правильно.
  • Сделайте это быстро

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

Ссылка

Ответ 6

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

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

Ответ 7

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

"Если вы спешите, пройдите долгий путь".

Ответ 8

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

Ответ 9

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

Ответ 10

"Преждевременная оптимизация - это корень всего зла". - Дональд Кнут

Ответ 11

согласны со всем вышеизложенным, но также:

когда вы решите, что хотите оптимизировать:

  • Исправить алгоритмические аспекты перед синтаксисом (например, не выполнять поиск в больших массивах)
  • Убедитесь, что вы доказали, что ваши изменения действительно улучшали ситуацию, измеряли все.
  • Комментируйте свою оптимизацию, чтобы следующий парень, видящий эту функцию, не упростил ее обратно туда, где вы начали с
  • Можете ли вы предварительно скопировать результаты или переместить вычисление туда, где это можно сделать более эффективно (например, db).

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

Ответ 12

Считываемость всегда выигрывает. Всегда. За исключением случаев, когда этого не происходит. И это должно быть очень редко.

Ответ 13

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

http://www.perl.com/pub/a/2004/01/16/regexps.html

Ответ 14

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

typedef Pixel PixelModifierFunction(Pixel);

void ModifyAllPixels(PixelModifierFunction);

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

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