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