Performance loss in loading plugins in a seperate app domain

  • Thread starter Thread starter dandorey1
  • Start date Start date
D

dandorey1

I'm currently in the process of writing a realtime telephony
application. I've designed it with a fairly simply plugin architecture.
When I first started reading about this the general suggestion was to
load each plugin in a seperate app domain. However performance is a
large concern for me.

Can anyone give me an idea of the performance impact I'm going to take
if I do start using a different app domain? Many of these plugins will
be directly involved with the realtime processing and the messages
being passed across the app domain would be small and chatty
(unavoidable).

Since my team or I will be writing all the future plugins I'm not
overly concerned with the disadvantages of keeping everything in a
single app domain (no protection of main engine, can't reload on the
fly, etc).

However if the performance impact is not that high, I do like the idea
of seperate app domains for the plugins.

Thanks for any insight!
 
Using separate app domains is a good idea, as it will allow you to
unload the plug in, should you need to. It will also allow the application
to sandbox your activity, placing restrictions on what the plug in can do.

If you don't have these requirements, then I would suggest not using a
separate app domain. Making calls across the app domain WILL have an
impact, since there is cross-app-domain calls taking place. Serialization
will occur (or moving proxies if derived from MarshalByRefObject) on return
values, parameters, etc, etc.

Since you have a protocol which is chatty and small, it could be
considerable. Of course, I would recommend to measure the impact, and see
if it affects you.

Hope this helps.
 
Back
Top