CODEWITHSUNDEEP
silverlightwindows-phone-7mvvm
Cranialsurge
Cranialsurge

Reputation: 245

Won't performance take a hit with the MVVM Light toolkit?

I've been using the popular MVVM Light toolkit: here for creating my Windows Phone applications and had a question regarding the pattern. For every page created, we create a new view model to keep the code behind clean and promote separation of concerns. However The ViewModelLocator's constructor contains an instantiation of each and every viewmodel.

The ViewModelLocator's constructor typically looks like this:

public ViewModelLocator()
    {
        ////if (ViewModelBase.IsInDesignModeStatic)
        ////{
        ////    // Create design time view models
        ////}
        ////else
        ////{
        ////    // Create run time view models
        ////}

        CreateMain();
        CreatePage2();
        CreatePage3();
        CreatePage4();
    }

If an application contains a bunch of pages, won't instantiating every ViewModel even for those views that might never be required cause a performance concern?

Am I missing something here?

Upvotes: 1

Views: 536

Answers (2)

aqwert
aqwert

Reputation: 10789

You don't have to create the objects in your constructor explicitly. You can defer them to the first time they are accessed. 

public MainPageViewModel MainPage
{
  if(_mainPageViewModel == null)
  {
    _mainPageViewModel = CreateMain(); 
  }
  return _mainPageViewModel;
}

By all means measure the performance as @Stuart has said, but it generally is a good idea to only create enough for what you need. So deferring the creation to the property getter is would be best.

However if the constriction of the view models are heavy then you could consider upfrint construction within the constructor while providing a progress bar to the user. Again that depends, measure performance, analyse your design to see what best suits your needs.

Upvotes: 1

Stuart
Stuart

Reputation: 66882

With any overhead or any concern about performance, it's a good idea to measure what the overhead/problem is.

It's true that when coding WP7 through .Net, C#, Silverlight, XAML, DataBinding and MVVMLight then you inserting a lot of "overhead" - and most of that overhead is there for the convenience of the coder, not for the benefit of the user.

However, the WP7 CPU, the video co-processor, the fast RAM and fast SolidState memory are all really quite quick - so there is room for some overhead, and you can use those frameworks to create delightful, responsive WP7 apps.

By all means worry about performance - but its best to drive those concerns through measurement to find out where you need to optimise, or where you need to hide the slowness behind some other UI feature.

Generally when I measure, I find that my performance bottlenecks aren't where I expect... I also discover that there are always trade-offs - e.g. in your concern here, the tradeoff might be that while the Locator construction code runs slower, the later lookup code can run quicker - so in-app navigation can be faster at the expense of slightly a marginally slower startup time.

Upvotes: 8

Related Questions