Re: Running GUI application in separate application domain

I'm pretty certain is has to do with Security Runtime Checks. When I turn
Code Access Security off (caspol -s off) the performance is fine and of
course the runtime security checks perfmon counter is zero.

This is where some of the confusion comes in. When CAS is turned on
sometimes the performance is good and sometimes it isn't. However, ever
since I've started looking at the security runtime checks performance counter
I've noticed that every time the performance is slow I'm doing huge amounts
of runtime security checks. On the order of 3200/sec. When CAS is on and
the peformance is good the runtime security checks counter is much lower,
maybe 300/sec - 500/sec. I can't figure out why sometimes this counter will
be high and other times it will be low for the same assemblies. I've
literally ran the program once and noticed poor performance and then ran the
same program again (no changes) and noticed good performance. Again, the
poor performing run was generating loads of runtime security checks and the
good performing run was not.
--
Thanks,
Nick


"nickdu" wrote:

> I just ran some more tests and captured perfmon logs for the two different
> scenarios. When I run the GUI components in the default app domain I get the
> following results (I only lists the ones that are significantly different and
> could potentially indicate the problem).
>
> .NET CLR Security\Total Runtime Checks: Min=122,443 Max=358,890 Delta=~236,000
> .NET CLR Memory\# Gen 0 Collections: Min=149 Max=9927 Delta=~9800
> .NET CLR Memory\% Time in GC: Average=6
> .NET CLR Memory\Allocated Bytes/sec: Average=12MB
> .NET CLR Memory\Finalization Survivors: Average=344
>
> The same counters for the scenario where the components are run in an
> appdomain different from the default domain is:
>
> .NET CLR Security\Total Runtime Checks: Min=124,677 Max=1,475,320 Delta=~1.3M
> .NET CLR Memory\# Gen 0 Collections: Min=762 Max=69,766 Delta=~69,000
> .NET CLR Memory\% Time in GC: Average=17
> .NET CLR Memory\Allocated Bytes/sec: Average=32MB
> .NET CLR Memory\Finalization Survivors: Average=38
>
> For for some reason running these components in a different application
> domain drastically increased the # of runtime security checks, # of gen 0
> collections, % Time in GC, and the allocated bytes/sec. Note that the server
> which generates the real time data feed is the same in both cases.
>
> Any ideas?
> --
> Thanks,
> Nick
>
>
> "nickdu" wrote:
>
> > I create two application domains. In each of those domains I create two GUI
> > controls. They do not communicate amongst each other. There should be no
> > remoting going on, at least as far as I can tell. Think of it this way:
> >
> > I have this current application, which you can think of as your typical
> > application. It has a mainform and some controls (though all of my controls
> > are modeless dialogs) and they all run in the default application domain.
> > Now you decide you want to run this whole thing in a different application
> > domain, other than the default. So in Main() of the default appdomain you
> > create a new appdomain and execute an assembly on a different thread. The
> > main of this new assembly does exactly what the original program did. Don't
> > know if this explains it any better. I hope so.
> >
> > --
> > Thanks,
> > Nick
> >
> >
> > "Lloyd Dupont" wrote:
> >
> > > > What remoting are we talking about. I create two components in one
> > > > application domain and two in another. They don't talk to each other.
> > > > There
> > > > should be no remoting/marshaling going on, that I know of. When I compare
> > > > the performance of this configuration against a "similar" application
> > > > which
> > > > creates these same components all in the default application domain the
> > > > performance is drastic. The multi-appdomain model is at least 10x slower.
> > > > --
> > > Now I wonder, if you want to display this component you have:
> > > 1. to put them on a visible form
> > > 2. respond to all the mouse move, mouse down, key and paint events
> > > 3. feed them some data.
> > >
> > > all of this takes a lot of method => a lot of remoting call
> > >
> > > or could you explain more in detail what you do?
> > > how you could avoid remoting while still having multiple app domain per
> > > component (assuming component = something inheriting from SWF.Control) ?
> > >
> > >
> > >
.

Relevant Pages