|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Running GUI application in separate application domainI'm trying to isolate "applications" into their own application domain within
a single process. I've quoted applications because it's a logical representation of an application. Basically it consists of a bunch of components supplied by some application group. I got this to work, somewhat. The problem is that the application performs roughly (and this has not been measured, but a guess based on the rendering of the application GUI) 10x slower than a similar (almost identical) application in which all of the components are created within the main (/default) application domain. Is there some inherent performance problem with running GUI applications in separate application domains? By the way, I'm also posting this to the dotnet general newsgroup and dotnet framework clr newsgroup. -- Thanks, Nick I've got some additional information. Via configuration I was able to move
all these components into a single application domain, separate from the default domain. The performance of this matches the performance of the existing application where all the components are in the default domain. In both of these scenarios I noticed the % Time in GC is around 7%. When these components are spread across two application domains the % Time in GC is around 20% and as I mentioned the performance appears to be about 10x worse. I'm running the application from my laptop which is a single processor machine. Why would separating the work of a single application to multiple application domains have such a drastic change on the GC? -- Show quoteThanks, Nick "nickdu" wrote: > I'm trying to isolate "applications" into their own application domain within > a single process. I've quoted applications because it's a logical > representation of an application. Basically it consists of a bunch of > components supplied by some application group. I got this to work, somewhat. > The problem is that the application performs roughly (and this has not been > measured, but a guess based on the rendering of the application GUI) 10x > slower than a similar (almost identical) application in which all of the > components are created within the main (/default) application domain. Is > there some inherent performance problem with running GUI applications in > separate application domains? > > By the way, I'm also posting this to the dotnet general newsgroup and dotnet > framework clr newsgroup. > > -- > Thanks, > Nick > components are created within the main (/default) application domain. Is your question is tricky because neither yes or no could be replied.> there some inherent performance problem with running GUI applications in > separate application domains? on one hand GUI has nothing to do with decreasing performance on the other hand Remoting has a lot to do with them. When 'application' or 'component' are in different application domain they can't call each other, you have to go through remoting to marshall call and return value. Although a specialized version of remoting with a faster in memory channel is used for inter domain communication, there is still a price to pay which visually perceptible, as you saw... 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. -- Show quoteThanks, Nick "Lloyd Dupont" wrote: > > components are created within the main (/default) application domain. Is > > there some inherent performance problem with running GUI applications in > > separate application domains? > your question is tricky because neither yes or no could be replied. > on one hand GUI has nothing to do with decreasing performance > on the other hand Remoting has a lot to do with them. > > When 'application' or 'component' are in different application domain they > can't call each other, you have to go through remoting to marshall call and > return value. > Although a specialized version of remoting with a faster in memory channel > is used for inter domain communication, there is still a price to pay which > visually perceptible, as you saw... > > > By the way, forget my second post. When I tried running all the components
in one appdomain, which was not the default appdomain, again the performance was very poor. I guess the first time was a fluke. By the way, I talk about performance but I guess some may be confused about what I mean. The components are grid components (classes derived from the SyncFusion grid) which are displaying real-time data updates over a TIB bus. When these same components are all run in the default application domain the application can keep up with the real-time updates. When I create two of the grids in one appdomain and two in another the performance decreases drastically. -- Show quoteThanks, Nick "nickdu" 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. > -- > Thanks, > Nick > > > "Lloyd Dupont" wrote: > > > > components are created within the main (/default) application domain. Is > > > there some inherent performance problem with running GUI applications in > > > separate application domains? > > your question is tricky because neither yes or no could be replied. > > on one hand GUI has nothing to do with decreasing performance > > on the other hand Remoting has a lot to do with them. > > > > When 'application' or 'component' are in different application domain they > > can't call each other, you have to go through remoting to marshall call and > > return value. > > Although a specialized version of remoting with a faster in memory channel > > is used for inter domain communication, there is still a price to pay which > > visually perceptible, as you saw... > > > > > > > What remoting are we talking about. I create two components in one Now I wonder, if you want to display this component you have:> 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. > -- 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) ? 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. -- Show quoteThanks, 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) ? > > >
Show quote
>I create two application domains. In each of those domains I create two yep that's clear.>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. > mmhh... does you Main() method is tagged with [STAThread] ? I *suppose* that [STAThread] and multiple app domain would create some internal remoting overhead.... but probably not that much.... mhh... just an idea... Yes, I did add the [STAThread] attribute to the Main() of this loaded
assembly. However, for the thread I started that calls AppDomain.ExecuteAssembly() I did not specify any apartment setting. I assume that's OK. -- Show quoteThanks, Nick "Lloyd Dupont" 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. > > > mmhh... > yep that's clear. > does you Main() method is tagged with [STAThread] ? > I *suppose* that [STAThread] and multiple app domain would create some > internal remoting overhead.... > but probably not that much.... mhh... just an idea... > > > "nickdu" <nic***@discussions.microsoft.com> wrote in message No, it's not, see my response to the same thread in dotnet.clr NG.news:BCE28936-4E13-4A90-98C1-AFAEC28C7D48@microsoft.com... > Yes, I did add the [STAThread] attribute to the Main() of this loaded > assembly. However, for the thread I started that calls > AppDomain.ExecuteAssembly() I did not specify any apartment setting. I > assume that's OK. > -- > Thanks, > Nick > Willy. 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? -- Show quoteThanks, 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) ? > > > > > > 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. -- Show quoteThanks, 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) ? > > > > > > > > > if you've got VS2005 you could run a performance session.
It will tells how much time you spend in your method (in absolute and % value). by running 2 session: 1 with multiple app domain, one without. you will be able to know which method takes more time, hence finding out which security check are done and why. -- Show quoteThere are 10 kinds of people in this world. Those who understand binary and those who don't. "nickdu" <nic***@discussions.microsoft.com> wrote in message news:F4CB5B6B-C41C-479A-A3CC-7B450E915AF6@microsoft.com... > 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) ? >> > > >> > > >> > >  |
|||||||||||||||||||||||
Other interesting topics