While Mango isn’t a silver bullet to fix performance, it does help a lot.  But there’s only so much that can be done on a platform level.  The developers of Windows Phone applications need to be smart about what they’re doing as well

Scrolling is the highest visibility performance metric to a user.  A poor, stuttering scrolling experience is going to lead to a poor user experience.  That poor user experience is going to yield poor ratings and reviews in the marketplace, and poor perception of your application.  Ultimately, that means no adoption of your application.  There was a lot done in Mango to help address this.  Let’s take a quick look at some of the ways to get our app moving fast.

The thread architecture in the Mango update has changed quite a bit.  It looks a little something like this:

• UI Thread - Handles IO and animations, layout, rendering, data binding
• BG thread - Dispatch, networking, parsing
• Compositor thread - Primitive animations are done here, and composited onto back buffer
• Touch thread - Explicitly for processing the touch events

You’re also going to see, due to a lot of optimizations in memory management in Mango, a 25-40% improvement in your application’s working set.  For free.

A couple tips that you can use to look at performance of your WP7 application:

• EnableDrawRegions - This will change colors of an overlay on redraw so you can visually see when WP7 has to redraw and relay your pages.
• The Pivot control is faster and lighter than the Panorma control; it doesn’t have to load ALL of the content on first load.  If you can use a Pivot experience, you probably should.
• Remember that controls expand at runtime to the sum of their parts.  If you’re not careful, the layout engine is going to get VERY busy.
• Specify exact widths and heights when possible to help the layout engine.  If you tell it what the value of something is, it won’t have to calculate it.
• Try and skip visibility convertors and add that value to your ViewModel if possible; there’s potential for big wins there by not having to run a convertor for all those elements.
• Skip image resizing on the fly.

One of the available tools on the internet to help with some performance problems is LoadingPivotItem.  This replacement for PivotItem adds a nice loading experience to PivotItems, loads the content for the item in the background, builds and processes the visual tree, and then brings it in.

You also get a new ProgressIndicator in Mango which provides an OS progress indicator control.  This will help your users realize that you’re actually doing something so they’re not staring a completely blank page wondering if something has gone wrong.

You should also move infrequently used things to other assemblies so that they’re not loaded on startup.  Some good examples here are settings pages, about pages, that sort of thing.

If you can get your raw startup time fast enough, just kill off your splash screen.  Your application will have a more native OS type experience and the perception of higher performance will be there (since you’re already starting fast anyway).

Lastly, make sure you muck with storage (IsolatedStorage, DB) off of a separate thread so that you don’t block your UI thread.

All of these things should go a long way to really snap up the performance of your application, and give your users what they’re looking for much more quickly.