Can I use App Domains in a WPF MVVM application to improve start up time, and only load assemblies if I need them?

user_7132313 0
Viewed 95

I have a .net WPF application which is getting slower and slower to load as more functionality is added. My client wants to add a lot more functionality. It currently takes over a minute to load.

Is it possible to isolate coding contained in assemblies say for "Sales Orders" so that it is only loaded if the user navigates to that visual state and loads the views and associated viewmodels in that assembly ?

If it is, I have some common assemblies for data and file IO classes. Can they be loaded at the start and shared by each App Domain, or would I need to load a local copy oif this assembly in each AppDomain.

Assuming this is possible, what would the startup coding look like for the application, and how would I load an assembly before navigating to a visual state which needed it?

Ideally I want to load my application to the initial menu in under 10 seconds and I don't mind further 5 to 10 second delays as they load different parts of the application.

I just have no idea if this is possible of how to go about it

appdomain mvvm wpf
3 Answers

I'm not sure if multiple AppDomains is something that fits well in WPF (IMO definitively not!). If you have complex functionality, with plenty features I would advice to try to perform sort of use-case analysis and split / decompose on smaller parts and implement "lazy loading".

Of course, depending on type of application, it may happen that during single user session (user launches application > performs his tasks/work > used closes application), if you have e.g. 100 features, user may use maybe 10 of them. So, at boot time there is no sense do anything at all with remaining 90 features (no sense to load, initialize views, view models, data etc.).

Other words:

  1. Identify features of your application and represent them as components. I can advice you to have a look here: https://qube7.com/guides/controller.html

    In above solution controller may represent single feature and encapsulate everything that the feature requires to operate.

  2. Identify features that during his session user with high probability will require anyway, then at boot time trigger/run controllers that represent those features.

  3. Remaining features treat as on-demand: initialize, load and run representing controllers only when user explicitly requests.

PS: You may use performance profiler (e.g. ANTS) to see where your bottlenecks are but I bet that the assembly loading won’t be biggest hit (assembly loading for sure does not takes 60sec) :)

user_152949840

Another good idea you can implement shadow loading side assembly (in the different thread) to the second AppDomain just after loading your UI, it would be more comfortable for users, because they can access their function immediately after full load of application. But let have a look at your application. Loading of one assembly takes time, about 300ms, how many additional assemblies do you have? Have you ever traced it with special tracing tool? What does exactly take such a long time while loading? One minute sounds too long for loading only assemblies, possible any other logic takes it?

user_68711390

I eventually found that I could dramatically speed up load time by using reflection to dynamically load the specific user control relating to the menu option selected. This reduced load time from 60 seconds to 3

App Domains was a red herring

user_71323130
Related