Каков минимальный штраф за пропускную способность Cross AppDomain?

Я пытаюсь свести к минимуму снижение производительности связи через AppDomains на той же машине. В моем примере игрушек класс А загружается в AppDomain 1. Он создает AppDomain 2 и загружает туда экземпляр класса 2 (класс 2 наследует от MarshalByRef), возвращая прокси. Затем класс 1 неоднократно вызывает метод прокси-сервера, который не возвращает никаких значений.

Получаю следующие результаты:

Нет AppDomains, оба класса загружаются в один и тот же AppDomain, а первый вызывает повторный метод на втором (метод не имеет параметров): 24 миллиона вызовы методов/сек
Два AppDomain, как описано выше, метод не имеет параметров или параметров "кровоточащих" строк: 340 000 методов вызовов/сек
Два AppDomains, как описано выше, один сериализуемый параметр (массив из двух строк): 64 000 вызовов методов/сек

Хотя я понимаю ограничение производительности между 2 и 3 (сериализация), я действительно не понимаю , почему я в 100 раз медленнее от случая 1 к случаю 2. Насколько я понимаю, после создания прокси все последующие вызовы методов должны быть действительно быстрыми, поскольку данные не сортируются из одного приложения в другой. Кто-нибудь теперь, почему общение через AppDomains происходит так медленно? Я что-то делаю неправильно?

PS1. Единственный совет, который у меня есть, это здесь: "И стоимость пересечения границы AppDomain неловко". Я предполагал, что он ссылается на сериализацию...

PS2. Я не считаю время создания AppDomain или прокси (мои тесты начинаются с первого вызова метода)

PS3. Я использую .NET 3.5 на машине WinXP SP3. Я также пробовал .NET 4.0 Beta 1 без существенных различий.

Ответ 1

Если вы подсчитываете строки IL, участвующие в каждом сценарии, вы увидите, что CLR выполняет намного больше, чем в 100 раз больше работы при удалении. Прямой вызов - это всего лишь несколько кодов операций, но при удалении используются несколько классов, реальные/прозрачные прокси, проверки безопасности, сериализация, yadda yadda yadda. Вам нужно будет решить эту проблему через дизайн - нет никакой волшебной пули для улучшения реализации через реализацию.

Ответ 2

Есть ли способ вызывать один вспомогательный метод, который принимает параметры о том, сколько раз вы хотите вызвать метод, который вам нужен? Выполнение вызова в Cross-AppDomain сильно зависит от реализации. Я считаю, что это может быть значительно лучше в CLR 4.0, но я не полностью разбираюсь в деталях.

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

Ответ 3

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