Является ли слабость Python проблемой производительности? - PullRequest
Новая
       37

Является ли слабость Python проблемой производительности?

0 голосов
/ 14 апреля 2020

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

Я использую Слабые ссылки, чтобы избежать установки постоянной ссылки l oop, которая предотвращает сборку мусора.

Однако во время профилирования я обнаружил, что очистка этих слабых ссылок на удивление дорогая - за исключением только минимума Сципи (производительность которого вполне понятна) .

Я увеличил производительность примерно на 35%, представив неиспользованные слабые ссылки как None:

Оригинал: 

  def clear_results(self):
        self._results = lambda: None    # Mimics weakref behaviour, but returns None

На 35% быстрее: 

def clear_results(self):
    self._results = None    # Requires check in the public accessor of self._results

Это также уничтожение слабого, что, по-видимому, требует времени - создание слабого даже не входит в список профилирования.

Это не кажется интуитивно понятным разумно - я что-то упустил?

1 Ответ

0 голосов
/ 14 апреля 2020

Я просто опубликую этот краткий обзор, чтобы закрыть вопрос. Почти вся информация поступает от @MisterMiyagi, и моя благодарность и вся заслуга ему.

Краткий ответ - «нет» - слабые стороны не вызывали проблем с производительностью, которые я видел. Более того, как указывает @MisterMiyagi, они даже не были нужны вообще, поскольку более поздние версии Python, чем я начал (V1.9), справляются с проблемой, которую я использовал для защиты от слабого обращения (*) 1003 *https://www.python.org/dev/peps/pep-0442/).

Мне удалось улучшить производительность по двум не связанным с этим вопросам, которые могут быть интересны другим:

  1. Мой "слабый ответ репликатор "(self._results = lambda: None) был на удивление медленным. Заменив это на self._results = None сэкономило достаточно времени.

  2. Я использовал listcomp для очистки результатов: [item.clear_results() for item in items]. Оказывается, это намного медленнее, чем прямая l oop - возможно, отчасти потому, что мне не нужно собирать результаты.

...