Производительность по сравнению с удобочитаемостью
Мне понравился метод Lost Koder. Я столкнулся с проблемами при попытке сериализации более сложных объектов, чьи члены / методы не сериализуемы. Вот моя реализация, которая работает с большим количеством объектов:
class Serializer(object):
@staticmethod
def serialize(obj):
def check(o):
for k, v in o.__dict__.items():
try:
_ = json.dumps(v)
o.__dict__[k] = v
except TypeError:
o.__dict__[k] = str(v)
return o
return json.dumps(check(obj).__dict__, indent=2)
14 ответов
Мой процесс для ситуаций, где я думаю производительность, может быть проблемой:
- Заставляют его работать.
- Проясняют.
- Проверяют производительность.
- , Если существуют значимые проблемы производительности: осуществите рефакторинг для скорости.
Примечание, что это не относится к высокоуровневым проектным решениям, которые более трудно изменить на более позднем этапе.
Я всегда запускаю с самой читаемой версии, о которой я могу думать. Если производительность является проблемой, я осуществляю рефакторинг. Если читаемая версия мешает делать вывод, я осуществляю рефакторинг.
ключ должен иметь хорошие тесты так, чтобы рефакторинг был легок.
я просматриваю удобочитаемость как № 1 самая важная проблема в коде, хотя работа правильно является вторым.
Удобочитаемость является самой важной. С современными компьютерами только самые интенсивные стандартные программы большинства требовательных приложений должны волноваться слишком много о производительности.
Я применяю здравый смысл - этот вид вещи является только одним из огромного количества компромиссов, которые разработка влечет за собой и имеет немного специальных характеристик, которые я вижу.
, Но быть более конкретным, подавляющее большинство людей, делающих странные нечитабельные вещи от имени производительности, делает их преждевременно и без измерения.
Программы должны быть записаны, чтобы люди читали, и только случайно, чтобы машины выполнились.
— Abelson & Sussman, SICP
, Правильно написанные программы, вероятно, легче к профиль и следовательно улучшают производительность .
Необходимо всегда идти для удобочитаемости сначала. Форма системы будет обычно развиваться, поскольку Вы разрабатываете ее, и реальные узкие места производительности будут неожиданны. Только, когда Вы имеете системное выполнение и видите вещественные доказательства - в соответствии с профилировщиком, или другой такой инструмент - будет лучший способ оптимизировать быть показанным.
, "Если Вы спешите, возьмите длинный путь вокруг".
Предпочтите удобочитаемость производительности, если Вы не можете доказать необходимость в производительности.
Я сказал бы, что необходимо только пожертвовать удобочитаемостью за производительность, если существует доказанная проблема производительности, это значительно. Конечно, "значительный" выгода там, и что является значительным и что не, должно быть характерно для кода, Вы продолжаете работать.
согласитесь со всем вышеупомянутым, но также и:
, когда Вы решаете, что хотите оптимизировать:
- Фиксируют алгоритмические аспекты перед синтаксисом (например, не делают поисков в больших массивах)
- , Удостоверяются, что Вы доказываете, что Ваше изменение действительно улучшало вещи, измеряет все
- Комментарий Ваша оптимизация так следующий парень, видящий, что функция не упрощает его назад туда, где Вы запустили от
- , Может Вы предварительно вычислять результаты или перемещать вычисление туда, где это может быть сделано эффективнее (как дб)
в действительности, сохраните удобочитаемость, пока Вы можете - нахождение, что неясная ошибка в оптимизированном коде является намного более трудной и раздражающей, чем в простом очевидном коде
"Преждевременная оптимизация является корнем всего зла". - Donald Knuth
Удобочитаемость всегда побеждает. Всегда. Кроме тех случаев, когда это не делает. И это должно быть очень редко.
время от времени, когда оптимизация необходима, я пожертвовал бы компактностью и сохранил бы улучшение производительности. жемчуг, очевидно, имеет некоторые глубокие воды для инфраструктуры в поисках отношения краткости/производительности, но столь же милый, как это должно записать остроты, человек, который приезжает для поддержания кода (кто, по моему опыту, обычно самостоятельно 6 месяцев спустя), мог бы предпочесть что-то больше в расширенном стиле, как зарегистрировано здесь:
Существуют исключения к преждевременному правилу оптимизации. Например, когда доступ к изображению в памяти, чтение пикселя не должны быть исключительной функцией. И при обеспечении пользовательских операций на изображении, никогда не делайте это как это:
typedef Pixel PixelModifierFunction(Pixel);
void ModifyAllPixels(PixelModifierFunction);
Вместо этого позвольте внешним функциям получить доступ к пикселям в памяти, хотя это более ужасно. Иначе Вы, несомненно, напишете медленный код, который необходимо будет осуществить рефакторинг позже так или иначе, таким образом, Вы делаете дополнительную работу.
, По крайней мере, это правда если Вы знаете, что собираетесь иметь дело с большими изображениями.
Мой любимый ответ на этот вопрос:
- Сделайте это работать
- Сделайте это правильно
- Сделайте это быстро
Что касается читабельности, то никому наплевать на читаемость, кроме следующего неудачника, который должен позаботиться о вашем коде. Однако, как говорится ... если вы серьезно относитесь к своему искусству, а это форма искусства, вы всегда будете стремиться сделать свой код максимально производительным, в то же время оставаясь читаемым для других. Мой друг и наставник (который является БАДАССОМ во всех смыслах) однажды любезно сказал мне во время проверки кода, что «дурак пишет код, понятный только им, а гений пишет код, понятный каждому». Я не уверен, откуда он это взял, но это застряло во мне.