Каково использование режима базовой оптимизации Python? (python -O)

У Python есть флаг -O, с которым вы можете выполнить интерпретатор. Опция будет генерировать "оптимизированный" байт-код (записанный в .pyo файлы) и заданный дважды, он отменит docstrings. На странице руководства Python:

-O Включить основные оптимизации. Это изменяет расширение имени файла для скомпилированных (байткодов) файлов с .pyc на .pyo. Учитывая дважды, вызывает отбрасывание docstrings.

Эта опция имеет две основные функции, которые я вижу:

Удалите все утверждения assert. Это торгует защитой от коррумпированного состояния программы для скорости. Но разве вам не нужна тонна утверждений для этого, чтобы иметь значение? У вас есть код, в котором это стоит (и разумно?)
Разделите все docstrings. В каком приложении использование памяти настолько критично, что это победа? Почему бы не толкнуть все в модули, написанные на C?

Какая польза от этой опции? Имеет ли он реальную ценность?

Ответ 1

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

def foo(x):
    assert x in huge_global_computation_to_check_all_possible_x_values()
    # ok, go ahead and use x...

Большинство утверждений не так, конечно, но важно помнить, что вы можете делать такие вещи.

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

Ответ 2

Другое использование для флага -O заключается в том, что значение встроенной переменной __debug__ установлено на False.

Итак, в основном, ваш код может иметь много путей "отладки", например:

if __debug__:
     # output all your favourite debugging information
     # and then more

который при запуске под -O даже не будет включен в качестве байт-кода в файле .pyo; бедный человек C-ish #ifdef.

Помните, что docstrings отбрасываются только тогда, когда флаг -OO.

Ответ 3

Если у вас есть утверждения в часто вызываемом коде (например, во внутреннем цикле), удаление их может, безусловно, иметь значение. Экстремальный пример:

$ 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]

В реальных сценариях экономия обычно будет намного меньше.

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

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

Ответ 4

Я никогда не сталкивался с серьезными причинами использования -O. Я всегда предполагал, что его основная цель - в случае, если в какой-то момент в будущем будет добавлена значительная оптимизация.

Ответ 5

Я полагаю, что самыми тяжелыми пользователями -O являются py2exe py2app и тому подобное.

Я лично никогда не нашел использование для -O напрямую.

Ответ 6

Вы очень многое поняли: он практически ничего не делает. Вы почти никогда не увидите скорость или прирост памяти, если только вы не сильно вредите для ОЗУ.

Ответ 7

Но разве вам не нужна тонна утверждений для этого, чтобы иметь значение? У вас есть код, где это стоит (и разумно?)

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

assert not any(a == b for a, b in zip(path, path[1:]))

Мне нравится спокойствие и ясность, которое это простое утверждение дает во время разработки. В производстве код обрабатывает некоторые большие графики, и эта одна строка может занимать до 66% времени выполнения. Таким образом, запуск с помощью -O дает значительное ускорение.