Каково использование основного режима оптимизации Python? (Python-O)
Я однажды был призван для рассмотрения mysql, который "прекратил работать". Я обнаружил, что файлы DB находились на Файловом сервере сетевых устройств, смонтированном с NFS2 и с максимальным размером файла 2 ГБ. И конечно же, таблица, которая прекратила принимать транзакции, была точно 2 ГБ на диске. Но относительно кривой производительности мне говорят, что она работала как чемпион до тех пор, пока она не работала вообще! Этот опыт всегда служит для меня в качестве хорошего напоминания, что всегда существуют размеры выше, и ниже того Вы естественно подозреваете.
6 ответов
Об удалении операторов assert: это стандартный вариант в мире C, где многие люди считают, что часть определения ASSERT состоит в том, что он не работает в производственном коде. Имеет ли значение их удаление или нет, зависит не столько от количества утверждений, сколько от того, сколько работы выполняют эти утверждения:
def foo(x):
assert x in huge_global_computation_to_check_all_possible_x_values()
# ok, go ahead and use x...
Большинство утверждений, конечно, не такие, но важно помнить, что вы можете делать такие вещи, как это.
Что касается удаления строк документации, это действительно кажется причудливым пережитком из более простых времен, хотя я предполагаю, что есть среды с ограниченным объемом памяти, где это может иметь значение.
Если у вас есть утверждения в часто вызываемом коде (например, во внутреннем цикле), их удаление, безусловно, может иметь значение. Экстремальный пример:
$ python -c 'import timeit;print timeit.repeat("assert True")'
[0.088717937469482422, 0.088625192642211914, 0.088654994964599609]
$ python -O -c 'import timeit;print timeit.repeat("assert True")'
[0.029736995697021484, 0.029587030410766602, 0.029623985290527344]
В реальных сценариях экономия обычно будет намного меньше.
Удаление строк документации может уменьшить размер вашего кода и, следовательно, вашего рабочего набора.
Во многих случаях влияние на производительность будет незначительным. , но, как всегда при оптимизации, единственный способ быть уверенным - это измерить.
Я никогда не встречал веских причин для использования -O . Я всегда предполагал, что его основная цель - на случай, если в какой-то момент в будущем будет добавлена значимая оптимизация.
Я полагаю, что самыми активными пользователями -O являются py2exe py2app и подобные.
Я лично никогда не находил использовать для -O напрямую.
Вы уже в значительной степени разобрались: он практически ничего не делает. Вы почти никогда не увидите прироста скорости или памяти, если только не сильно пострадаете от ОЗУ.
Другой вариант использования флага -O состоит в том, что для значения встроенной переменной __ debug __ установлено значение False .
Таким образом, в основном ваш код может иметь множество «отладочных» путей, например:
if __debug__:
# output all your favourite debugging information
# and then more
, которые при работе под -O даже не будут включены в качестве байт-кода в . файл pyo ; C-ish #ifdef для бедняков.
Помните, что строки документации удаляются только , когда флаг -OO .