Какое минимальное снижение производительности связи Cross AppDomain?

Question

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

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

1. Нет доменов приложений, оба класса загружаются в один и тот же домен приложений, и первый вызывает метод повторно для второго (метод не имеет параметров): 24 миллиона вызовов метода / сек
2. Два AppDomain, как описано выше, метод не имеет параметров или строковых параметров: 340.000 вызовов методов / сек
3. Два домена приложений, как описано выше, один сериализуемый параметр (массив из двух строк): 64 000 вызовов метода / с

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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