Python - оптимизировать, не импортируя на уровне модуля? - PullRequest
4 голосов
/ 02 ноября 2010

В такой среде, как Django, я представляю, что если пользователь попадает на страницу (запустив функцию представления "some_page"), и у вас есть 8 импортов в верхней части модуля, которые не имеют отношения к этому представлению, Вы тратите впустую циклы на тех импорте. Мои вопросы:

  1. Достаточно ли большого количества ресурсов, чтобы оказать влияние на сайт с большим трафиком?
  2. Это настолько плохая практика для импорта внутри функции для этой цели, что ее следует избегать при указанном воздействии?

Примечание. Это можно считать преждевременной оптимизацией, но я не заинтересован в этом аргументе. Предположим, ради практической теории, что это законченный сайт с большим количеством трафика, который необходимо оптимизировать всеми возможными способами, и код приложения, а также БД были полностью оптимизированы 50 администраторами и разработчиками базы данных PhD. и этот импорт - единственное, что осталось.

Ответы [ 5 ]

15 голосов
/ 02 ноября 2010

Нет, не делай этого.В обычной среде выполнения Python в Интернете (mod_wsgi, gunicorn и т. Д.), Когда ваш процесс запускается, эти импорты будут выполняться, а затем все последующие запросы не будут повторно выполнять скрипт.Если вы поместите импорт в функции, они будут обрабатываться при каждом вызове функции.

5 голосов
/ 02 ноября 2010

Да, это плохая практика для импорта на уровне функций. Используя разумный импорт в верхней части модуля, вы создаете единовременную небольшую стоимость. Однако, если вы поместите импорт в функцию, вы будете нести затраты на импорт при каждом запуске этой функции. Таким образом, вместо импорта в функцию, просто импортируйте вверху модуля.

Несколько вещей, которые вы можете сделать, чтобы очистить и улучшить ваш импорт:

  • Не используйте дикий импорт, например from x import *
  • Где возможно, просто используйте обычный импорт, например, import x
  • Попробуйте разбить ваш код на более мелкие модули, которые можно вызывать по отдельности, чтобы было выполнено меньше операций по импорту

Кроме того, размещение импорта в верхней части модуля является делом стиля. Есть причина, почему PEP 8 говорит, что модули нужно импортировать сверху. Это намного удобочитаемее и удобнее в обслуживании.

Наконец, некоторые операции импорта на уровне функций могут вызвать проблемы совместимости в будущем, поскольку from x import * не является допустимым Python 3.x на уровне функций.

4 голосов
/ 02 ноября 2010

1) Ответ - нет.Django / Python не похож на PHP.Весь ваш модуль не будет интерпретироваться при каждом просмотре страницы, как это происходит с PHP-включениями.Модуль будет в памяти, и каждый просмотр страницы будет выполнять простой вызов функции для вашего представления.

2) Да, это будет контр-оптимизация для импорта на уровне представления.

1 голос
/ 28 ноября 2010
  1. Нет.Та же причина, что и у других ответов.

  2. Да.Причина та же, что и у других ответов.

Кстати, вы также можете выполнять импорт лениво.Например, Importing toolkit может «импортировать» модуль в коде верхнего уровня, но модуль фактически не загружается, пока не получен доступ к одному из атрибутов.

0 голосов
/ 30 сентября 2012

Иногда имеет смысл следующая табличка:

foo = None

def foorify():
    global foo
    if not foo: from xxx import foo

    foo.bar()

Это имеет смысл, когда фориоризация обусловлена ​​чем-то, что редко изменяется, например, один сервер дурачит, а другой никогда не делает, или если вы не хотите или не можете безопасно импортировать foo при запуске приложения или большинстве тестов.

...