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

Question

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

typedef Pixel PixelModifierFunction(Pixel);

void ModifyAllPixels(PixelModifierFunction);

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

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

Answer 4

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

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