Что выигрывает время, отключая сборку мусора? - PullRequest
4 голосов
/ 24 декабря 2010

Я читал код для модуля timeit и заметил этот сегмент:

gcold = gc.isenabled()
gc.disable()
timing = self.inner(it, self.timer)
if gcold:
    gc.enable()

Это просто сохраняет состояние сборки мусора (включено или выключено) и затем выключает его. Функция inner выполняет синхронизируемый оператор. Затем он возвращает сборщик мусора в старое состояние.

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

Ответы [ 2 ]

5 голосов
/ 24 декабря 2010

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

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

3 голосов
/ 07 июля 2011

Конечно, этот код должен быть написан так?

gcold = gc.isenabled()
gc.disable()
try:
    timing = self.inner(it, self.timer)
finally:
    if gcold:
        gc.enable()

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

Я сообщил об ошибках.python.org , и это было исправлено в Python 2.7.3 и 3.2.2.

...