Производительность против удобочитаемости
Читая этот вопрос, я обнаружил это как (обратите внимание на кавычки) "код" для решения проблемы (кстати, это perl).
100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*
Очевидно, что это интеллектуальный пример без реальных (я надеюсь никогда не увидеть этого в реальном коде в моей жизни) последствий, но когда вам приходится делать выбор, когда вы жертвуете читабельностью кода для производительности? Применяете ли вы только здравый смысл, всегда ли вы делаете это в крайнем случае? Каковы ваши стратегии?
Изменить: Извините, видя ответы, я мог бы сформулировать вопрос плохо (английский не мой родной язык). Я не имею в виду производительность в сравнении с читабельностью только после того, как вы написали код, я спрашиваю о том, прежде чем вы его напишите. Иногда вы можете предвидеть улучшение производительности в будущем, делая более темный дизайн или предоставляя некоторые свойства, которые сделают ваш класс темнее. Вы можете решить, что будете использовать несколько потоков или только один, потому что ожидаете масштабируемости, которую могут дать такие потоки, даже если это сделает код намного более сложным для понимания.
14 ответов
Мой процесс для ситуаций, когда я думаю, что производительность может быть проблемой:
- Сделай так, чтоб это работало.
- Уточни.
- Проверьте производительность.
- Если есть существенные проблемы с производительностью: рефакторинг для скорости.
Обратите внимание, что это не относится к проектным решениям более высокого уровня, которые сложнее изменить на более позднем этапе.
Я всегда начинаю с самой читаемой версии, которую только могу себе представить. Если производительность является проблемой, я рефакторинг. Если читаемая версия затрудняет обобщение, я делаю рефакторинг.
Ключ в том, чтобы иметь хорошие тесты, чтобы рефакторинг был легким.
Я рассматриваю удобочитаемость как самую важную проблему в коде, хотя работа над ней занимает второе место.
Читаемость является наиболее важной. С современными компьютерами только самые интенсивные процедуры самых требовательных приложений должны слишком беспокоиться о производительности.
Мой любимый ответ на этот вопрос:
- Сделай так, чтоб это работало
- Сделать это правильно
- Сделай это быстро
С точки зрения вещей никто не дает дерьма о читабельности, кроме следующего несчастного дурака, который должен заботиться о вашем коде. Тем не менее, как говорится... если вы серьезно относитесь к своему искусству, и это художественная форма, вы всегда будете стремиться сделать свой код максимально формальным, каким он может быть, оставаясь при этом читаемыми для других. Мой друг и наставник (который является BADASS во всех отношениях) однажды милостиво сказал мне в обзоре кода, что "дурак пишет код, который могут понять только они, гений пишет код, который может понять каждый". Я не уверен, откуда он это взял, но это застряло у меня.
Программы должны быть написаны для того, чтобы люди могли читать, и только для машин.
- Abelson & Sussman, SICP
Хорошо написанные программы, вероятно, легче профилировать и, следовательно, повысить производительность.
Вы всегда должны идти на удобочитаемость в первую очередь. Форма системы обычно будет меняться по мере ее разработки, и узкие места в реальной производительности будут неожиданными. Лучший способ оптимизации будет раскрыт только тогда, когда система запущена и вы сможете увидеть реальные доказательства, предоставленные профилировщиком или другим подобным инструментом.
"Если вы спешите, пройдите долгий путь".
Согласен со всем вышесказанным, но также:
когда вы решите, что хотите оптимизировать:
- Исправьте алгоритмические аспекты перед синтаксисом (например, не выполняйте поиск в больших массивах)
- Убедитесь, что вы доказали, что ваши изменения действительно улучшили ситуацию, измерьте все
- Прокомментируйте свою оптимизацию, чтобы следующий парень, увидев эту функцию, не упростил ее до того места, откуда вы начали
- Можете ли вы предварительно вычислить результаты или переместить вычисление туда, где это можно сделать более эффективно (например, в БД)
по сути, сохраняйте читабельность как можно дольше - найти скрытую ошибку в оптимизированном коде гораздо сложнее и раздражает, чем в простом очевидном коде
Я применяю здравый смысл - такого рода вещи являются лишь одним из множества компромиссов, которые влечет за собой разработка, и у них мало особых характеристик, которые я могу видеть.
Но, чтобы быть более конкретным, подавляющее большинство людей, делающих странные нечитаемые вещи во имя исполнения, делают их преждевременно и без измерения.
"Преждевременная оптимизация - корень всего зла". - Дональд Кнут
Я бы сказал, что вы должны жертвовать удобочитаемостью ради производительности, только если есть серьезная проблема с проверенной производительностью. Конечно, "существенным" является подвох, и что важно, а что нет, должно быть специфично для кода, над которым вы работаете.
Выбирайте удобочитаемость, а не производительность, если вы не можете доказать, что вам нужна производительность.
Читаемость всегда побеждает. Всегда. За исключением случаев, когда это не так. И это должно быть очень редко.
Иногда, когда необходима оптимизация, я бы предпочел пожертвовать компактностью и сохранить повышение производительности. У perl, очевидно, есть глубокие возможности для поиска краткости и производительности, но, как ни странно, писать однострочные тексты - человек, который приходит поддержать ваш код (по моему опыту, обычно я сам через 6 месяцев)) может предпочесть что-то большее в расширенном стиле, как описано здесь:
Есть исключения из правила преждевременной оптимизации. Например, при доступе к изображению в памяти чтение пикселя не должно быть функцией вне линии. А при обеспечении пользовательских операций над изображением никогда не делайте так:
typedef Pixel PixelModifierFunction(Pixel);
void ModifyAllPixels(PixelModifierFunction);
Вместо этого позвольте внешним функциям получать доступ к пикселям в памяти, хотя это более уродливо. В противном случае вы наверняка напишите медленный код, который потом придется реорганизовать позже, так что вы выполняете дополнительную работу.
По крайней мере, это правда, если вы знаете, что собираетесь работать с большими изображениями.