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 framework clr newsgroup.
--
Thanks,
Nick
8  2658 
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?
--
Thanks,
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 framework clr newsgroup.
--
Thanks,
Nick
I suspect that most of your problem is related to Marshalling the
objects across the app domains. The additional objects that are needed
to create this and the proxies could the additional GC work that needs
to occurs.
nickdu wrote: 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?
What marshaling? All the components are created in their appdomain. There
should be no marshaling going on.
Also, forget my last post. I ran it again with all the components in one
appdomain, other than the main appdomain, and the performance was very poor.
I guess the first time I tried that was just some sort of fluke. Though I
don't believe in flukes. My guess is that something is screwed up and most
of the time it's screwed up in the same way which causes the performance
problem.
--
Thanks,
Nick
"John Murray" wrote: I suspect that most of your problem is related to Marshalling the
objects across the app domains. The additional objects that are needed
to create this and the proxies could the additional GC work that needs
to occurs.
nickdu wrote: 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?
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.
--
Thanks,
Nick
"nickdu" wrote: What marshaling? All the components are created in their appdomain. There
should be no marshaling going on.
Also, forget my last post. I ran it again with all the components in one
appdomain, other than the main appdomain, and the performance was very poor.
I guess the first time I tried that was just some sort of fluke. Though I
don't believe in flukes. My guess is that something is screwed up and most
of the time it's screwed up in the same way which causes the performance
problem.
--
Thanks,
Nick
"John Murray" wrote:
I suspect that most of your problem is related to Marshalling the
objects across the app domains. The additional objects that are needed
to create this and the proxies could the additional GC work that needs
to occurs.
nickdu wrote: 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?
I'm not sure if this applies to your situation...there is a limitation in
the current BCL that prevents GUI components from being instantiated in
separate appdomains and that are all hosted in a GUI framework running in
its own appdomain. In other words, you cannot share GUI components across
appdomains. It's not that everything does not work, but some important
aspects don't work right. You can run a GUI framework in an appdomain other
then the default and have it host other GUI components, so long as all the
GUI pieces are all running in the same appdomain. You can share non-GUI
components across appdomain boundaries without apparent problems (otherwise
remoting would be completely useless). This may be related to the
performance problem you are seeing.
"nickdu" <ni****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com... 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.
--
Thanks,
Nick
"nickdu" wrote:
What marshaling? All the components are created in their appdomain.
There
should be no marshaling going on.
Also, forget my last post. I ran it again with all the components in one
appdomain, other than the main appdomain, and the performance was very
poor.
I guess the first time I tried that was just some sort of fluke. Though
I
don't believe in flukes. My guess is that something is screwed up and
most
of the time it's screwed up in the same way which causes the performance
problem.
--
Thanks,
Nick
"John Murray" wrote:
> I suspect that most of your problem is related to Marshalling the
> objects across the app domains. The additional objects that are needed
> to create this and the proxies could the additional GC work that needs
> to occurs.
>
>
>
>
>
> nickdu wrote:
> > 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?
>
I'm hoping it's not related as I'm not attempting to share components across
appdomains.
--
Thanks,
Nick
"David Levine" wrote: I'm not sure if this applies to your situation...there is a limitation in
the current BCL that prevents GUI components from being instantiated in
separate appdomains and that are all hosted in a GUI framework running in
its own appdomain. In other words, you cannot share GUI components across
appdomains. It's not that everything does not work, but some important
aspects don't work right. You can run a GUI framework in an appdomain other
then the default and have it host other GUI components, so long as all the
GUI pieces are all running in the same appdomain. You can share non-GUI
components across appdomain boundaries without apparent problems (otherwise
remoting would be completely useless). This may be related to the
performance problem you are seeing.
"nickdu" <ni****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com... 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.
--
Thanks,
Nick
"nickdu" wrote:
What marshaling? All the components are created in their appdomain.
There
should be no marshaling going on.
Also, forget my last post. I ran it again with all the components in one
appdomain, other than the main appdomain, and the performance was very
poor.
I guess the first time I tried that was just some sort of fluke. Though
I
don't believe in flukes. My guess is that something is screwed up and
most
of the time it's screwed up in the same way which causes the performance
problem.
--
Thanks,
Nick
"John Murray" wrote:
> I suspect that most of your problem is related to Marshalling the
> objects across the app domains. The additional objects that are needed
> to create this and the proxies could the additional GC work that needs
> to occurs.
>
>
>
>
>
> nickdu wrote:
> > 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?
>
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'm hoping it's not related as I'm not attempting to share components across
appdomains.
--
Thanks,
Nick
"David Levine" wrote:
I'm not sure if this applies to your situation...there is a limitation in
the current BCL that prevents GUI components from being instantiated in
separate appdomains and that are all hosted in a GUI framework running in
its own appdomain. In other words, you cannot share GUI components across
appdomains. It's not that everything does not work, but some important
aspects don't work right. You can run a GUI framework in an appdomain other
then the default and have it host other GUI components, so long as all the
GUI pieces are all running in the same appdomain. You can share non-GUI
components across appdomain boundaries without apparent problems (otherwise
remoting would be completely useless). This may be related to the
performance problem you are seeing.
"nickdu" <ni****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com... 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.
--
Thanks,
Nick
"nickdu" wrote:
> What marshaling? All the components are created in their appdomain.
> There
> should be no marshaling going on.
>
> Also, forget my last post. I ran it again with all the components in one
> appdomain, other than the main appdomain, and the performance was very
> poor.
> I guess the first time I tried that was just some sort of fluke. Though
> I
> don't believe in flukes. My guess is that something is screwed up and
> most
> of the time it's screwed up in the same way which causes the performance
> problem.
> --
> Thanks,
> Nick
>
>
> "John Murray" wrote:
>
> > I suspect that most of your problem is related to Marshalling the
> > objects across the app domains. The additional objects that are needed
> > to create this and the proxies could the additional GC work that needs
> > to occurs.
> >
> >
> >
> >
> >
> > nickdu wrote:
> > > 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?
> >
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'm hoping it's not related as I'm not attempting to share components across
appdomains.
--
Thanks,
Nick
"David Levine" wrote:
I'm not sure if this applies to your situation...there is a limitation in
the current BCL that prevents GUI components from being instantiated in
separate appdomains and that are all hosted in a GUI framework running in
its own appdomain. In other words, you cannot share GUI components across
appdomains. It's not that everything does not work, but some important
aspects don't work right. You can run a GUI framework in an appdomain other
then the default and have it host other GUI components, so long as all the
GUI pieces are all running in the same appdomain. You can share non-GUI
components across appdomain boundaries without apparent problems (otherwise
remoting would be completely useless). This may be related to the
performance problem you are seeing.
"nickdu" <ni****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com...
> 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.
>
> --
> Thanks,
> Nick
>
>
> "nickdu" wrote:
>
>> What marshaling? All the components are created in their appdomain.
>> There
>> should be no marshaling going on.
>>
>> Also, forget my last post. I ran it again with all the components in one
>> appdomain, other than the main appdomain, and the performance was very
>> poor.
>> I guess the first time I tried that was just some sort of fluke. Though
>> I
>> don't believe in flukes. My guess is that something is screwed up and
>> most
>> of the time it's screwed up in the same way which causes the performance
>> problem.
>> --
>> Thanks,
>> Nick
>>
>>
>> "John Murray" wrote:
>>
>> > I suspect that most of your problem is related to Marshalling the
>> > objects across the app domains. The additional objects that are needed
>> > to create this and the proxies could the additional GC work that needs
>> > to occurs.
>> >
>> >
>> >
>> >
>> >
>> > nickdu wrote:
>> > > 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?
>> >
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: David Olive |
last post by:
Hi guys,
I'm having a bit of a problem getting a VB .NET console app to run happily
as a scheduled task. The app itself generates a bunch of word documents on a
file share on another server by...
|
by: Jeffrey Palermo, MCAD.Net |
last post by:
I have some classes that control file processing in c#. The files come
from a mainframe and may take some time for each to process. I use the
Threadpool to process multiple files at once. Each...
|
by: EO |
last post by:
I'm using an ISP with poor tech support. I apologize if this is more of an
ISP question, but it is an asp.net question as well.
I have a root domain pointing to a root level folder. There are...
|
by: cdlipfert |
last post by:
Our intranet is running under windows integrated security. We have
domain users that want to access our intranet site via ssl vpn. SSL
VPN can not authenticate against services that run under...
|
by: nickdu |
last post by:
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...
| | |
by: seb |
last post by:
Hi,
I am using pygtk for the first times.
I am wondering what would be the best "pattern" to interface pygtk with
a thread.
The thread is collecting informations (over the network for...
|
by: Lloyd Sheen |
last post by:
While using VS 2005 Pro I get this about 50% of the time.
I run the app. See whats wrong. Stop the app (stop debugging button).
Make changes and then click the start debugging button.
If I...
|
by: Steve |
last post by:
Hello-
Your assistance with this issue is greatly appreciated.
Environment:
- Load-balanced IIS 6.0 servers (Win2003)
- web servers point (via UNC path) to a Microsoft File Cluster on...
|
by: =?Utf-8?B?U2hpdmEgUmFtYW5p?= |
last post by:
I have a windows application with multiple forms & another web application.
Now I need a parent EXE or Application which need to act as a container to
these application.
Example :
My existing Web...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
