Вопрос:

Как реализации Python обрабатывают обмен контекста во время вызовов функций?

python performance interpreted-language

210 просмотра

1 ответ

97 Репутация автора

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

В настоящее время этот прокси-сервис представляет собой простой объект, содержащий список кортежей с именами функций и ссылку на объект, которому он принадлежит. Каждый раз, когда модуль сталкивается с командой, которая не является частью его собственных методов, поведение по умолчанию будет отправлять его в эту прокси-службу, которая будет проверять, есть ли кто-нибудь в сети, способный выполнить ее. Если он кого-то находит, прокси-сервер перенаправляет вызов функции нужному объекту, а затем отправляет возврат вызывающей стороне, как только он его получает.

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

Мой вопрос тогда такой:

Как изменения контекста, такие как это, обрабатываются в реализациях Python? И какую оптимизацию я могу сделать, чтобы снизить влияние таких изменений контекста?

PS: имя прокси может вводить в заблуждение, но это не сетевое приложение. Все это выполняется в одном процессе на одной машине.

Редактировать: как здесь спросили, более конкретный пример.

class forwardToProxy:
       dict = {} #this dictionary would contain the names of commands such as "deleteName"
                 #and a first class function bound to the part of the program currently
                 #responsible for executing that command.

       def forward_command(command, arg):
           return dispatch[command](arg)

Это один из примеров того, что я имел в виду для прокси-объекта. Единственное, что делает этот класс, это передает команды тем частям программы, которые в данный момент назначены для выполнения. Мой вопрос касается последствий использования такого рода структуры.

  • Каждый вызов, который делает модуль, создает новый экземпляр этого класса в памяти, пока он не разрешится?

  • Если бы команда должна была быть перенаправлена ​​в модуль, который впоследствии переадресует другую команду и заставил бы другой модуль переслать еще одну команду, сколько экземпляров этого объекта будет ожидать в памяти возможного возврата?

  • Что именно происходит в памяти каждый раз, когда мы выполняем вызов функции в различных реализациях Python? (Пожалуйста, объясните как для одного и того же модуля, так и для вызовов внешнего модуля)

  • Какие оптимизации можно использовать, чтобы уменьшить влияние таких изменений контекста (поможет ли, например, @staticmethod)?

Автор: Althis Источник Размещён: 08.11.2017 10:49

Ответы (1)


1 плюс

3208 Репутация автора

Интересная тема. Честно говоря, Python вряд ли будет работать быстро, однако я наблюдаю все больший спрос на это.

Короче говоря:

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

Немного длиннее объяснение:

Я знаю, что именованный кортеж используется, когда в игру вступают оптимизации пространства. Причина заключается в том, что с именованным кортежем все ключи одинаковы и сохраняются один раз. Таким образом, вы можете сэкономить место в определении прокси. Однако, если вы вызываете функцию, она создает область видимости, которая есть dict. Вот как работает Python. Как это оптимизировать? Ну, вы должны написать это в C, чтобы иметь полный контроль над тем, что и когда выделяется.

Автор: Michał Zaborowski Размещён: 17.11.2017 06:39
Вопросы из категории :
32x32