Re: Running GUI application in separate application domain



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" <nickdu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E9209AD2-0F3E-4882-A8F8-3A7BB35FF6F4@xxxxxxxxxxxxxxxx
> 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?
>> >


.



Relevant Pages

  • Re: Running GUI application in separate application domain
    ... scenarios. ... When I run the GUI components in the default app domain I get the ... ..NET CLR Memory\Allocated Bytes/sec: Average=12MB ... appdomain different from the default domain is: ...
    (microsoft.public.dotnet.general)
  • Re: Running GUI application in separate application domain
    ... Nick ... you cannot share GUI components across ... You can run a GUI framework in an appdomain other ... >> SyncFusion grid) which are displaying real-time data updates over a TIB ...
    (microsoft.public.dotnet.general)
  • Re: Running GUI application in separate application domain
    ... Application domains are great for server style applications ... > the appdomain I want them in. ... > components are grid components ... >>> all these components into a single application domain, separate from ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Sockets and AppDomains
    ... > network stream to go through the main AppDomain. ... > in terms of performance and i beleive that marshaling those buffers ... > though about passing the actual Socket handler, ...
    (microsoft.public.dotnet.framework)

Loading