Archive

Archive for the ‘Performance’ Category

Silverlight for Windows Phone 7 Performance Session at PDC!

October 28th, 2010 Oren 1 comment

It’s that time of year again – PDC 2010 kicks of tomorrow! Join the Silverlight Performance Team as we take you through the high level analysis of common performance issues that apps commonly run into. I’ll be giving a live session titled “Optimizing Performance for Silverlight WP7 Apps” at 3:15pm (PDT) on day 1 (28 October 2010).

Even if you couldn’t make it here to heckle me in person, the rest of the team will be online and answering your questions (or heckling on your behalf) as you watch the live stream via the online player, which you’ll be able to find at http://player.microsoftpdc.com.

Make sure to check out the session before mine (“Things I Wish I Knew about Building WP7 Apps” by Jaime Rodriguez) and all of the rest of the Windows Phone 7track. There’s other great content at PDC that’s worth checking out, but we all know that that’s secondary!

See you there!

WP7 Perf Tip #6: Be smart about graphics (use JPEG where possible)

October 3rd, 2010 Oren 1 comment

Take Away’s:

  1. Wherever possible (i.e. no transparency) use JPEG images since these decode faster than PNG
  2. Make sure your images are correctly sized (you don’t want to waste cycles with resizing on the fly)
  3. Always compile your images with a “Build Action” of “Content” instead of the default “Resource”

Some Background:

  1. JPEG (JPG) decodes faster, simple as that. The difference will continue to shrink over time, but every cycle is important on the phone, especially on image intensive applications.Don’t take this to mean “never use PNG”, rather, PNG is slower so only use it when you need it (transparency) as opposed to for everything as a generic default.
  2. Although resizing is quick (even if it looks ugly) there is no point wasting those cycles resizing images on the fly (Silverlight will do this for you) if you can already size the images correctly from the start.
  3. The default when adding new images is to set “Build Action” to “Resource” (under the Properties window). Make sure to always change this to “Content” in order to reduce the size of your DLL, speeding up both app load and image load.

    The properties window, with the correct "Build Action" set


WP7 Perf Tip #5: Check your memory usage

September 28th, 2010 Oren 2 comments

Two for the price of one today!

Take Aways:

  1. Make sure your memory usage is below 90MB.
  2. Always check your memory usage while you’re developing your app (preferably on device) by using the following code:
long deviceTotalMemory = (long)DeviceExtendedProperties.GetValue("DeviceTotalMemory");
long applicationCurrentMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage");
long applicationPeakMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationPeakMemoryUsage");

Why?

The Windows Phone 7 Application Certification Requirements specify (as of 28th of September 2010):

5.2.5 Memory Consumption

The application must not exceed 90 MB of RAM usage. However, on devices that have more than 256 MB of memory, an application can exceed 90 MB of RAM usage. The DeviceExtendedProperties class can be used to query the amount of memory on the device and modify the application behavior at runtime to take advantage of additional memory. For more information, see the DeviceExtendedProperties class in MSDN.

Since you have a hard limit of 90MB (exceedable in some cases) it’s worth checking that you’re not getting anywhere near that while your app is running. The code above will give you the Peak (which is important to make sure you’ve never crossed the 90MB barrier) and the current memory. If you call that out every now and then you should be able to get a pretty good idea of how your memory fluctuates during the lifetime of the app.

Can I Go Above 90MB?

Sure – but be careful! If you’re app is memory intensive and would benefit from a little extra breathing room, then feel free to add some extra logic which dynamically loads more items into memory until a certain limit is hit. Note though that there is no defined limit above the 90MB barrier, so expect this to be clarified in the future.

Kudos

Kudos go to Stefan Wick, Principal Test Manager for pushing this code

WP7 Perf Tip #4: Use fully qualified paths when setting the source property

September 28th, 2010 Oren No comments

File this one under “Sad, but True”…

Take Away’s:

Always prefix your source paths with a “/” (full-qualified path) instead of simply using relative paths.

Correct:

 <Image Source="/Resources/Images/Background.jpg"> 

Incorrect:

 <Image Source="Resources/Images/Background.jpg"> 

But they both work!?!

True, both of these will work, equally well (visually), but performance wise the relative path will do extra lookups which waste time, and can hit the SD card more than you want it to (causing further slow downs). This is something that we will fix on our side in the future – since all storage is isolated and we can assume that there is always a “/” (if there is no “..”). For now, it doesn’t hurt to get the extra performance boost by simply prefixing your paths with a “/”.

Note:

As Luke Kim, a friend from Microsoft, pointed out “/” paths are not really full qualified paths. To make things clear though, I use the term “full qualified” since we are within the confines of the .NET IsolatedStorage framework and there is no access to the rest of the system, “/” paths are as fully qualified as you get (without actual URI specifiers). Thanks for pointing this out!

WP7 Perf Tip #3: Read the performance document

September 11th, 2010 Oren 1 comment

This is kind of obvious – but important. Read the White Paper which was written by the Silverlight performance team (mainly Shane Guillet) and browse through the samples that come with it. In these blog posts I’ll try to distill specific items from the paper into blog format, but you can’t replace the feel of the complete paper.

Additionally check out the performance video with Shane, which runs through a lot of the samples from the document and distills specific tips and tricks to get your app running smoothly: http://channel9.msdn.com/shows/Inside+Windows+Phone/Inside-Windows-Phone-03-Optimizing-Windows-Phone-Silverlight-applications/

WP7 Perf Tip #2: Know your ProgressBar

August 24th, 2010 Oren No comments

Take Away’s:

  1. Do not use the built in ProgressBar straight up, use Jeff’s template
  2. When you’re done with an indeterminate ProgressBar, make sure to toggle IsIndeterminate to False and Collapse the bar
  3. General: Always make sure to stop animations / remove animating controls when they’re no longer needed

Some Background:

Due to a bunch of different reasons the shipping ProgressBar control is suboptimal and will actually be UI thread bound – meaning that if your UI thread is stuck working, your ProgressBar will be stuck as well. Not a great situation for a ProgressBar, huh?

That said, we’re not leaving you high and dry. Jeff Wilcox has a great solution which changes the template for the ProgressBar to only run on the Render thread – meaning that it will continue ticking, even when you’re doing your heavy loading work on the UI thread. That said, it still comes with a gotcha – don’t forget to set IsIndeterminate to False and to Collapse the bar once your done (instead of just setting Visibility to Hidden) so that the ProgressBar doesn’t continue to tick in the background, eating up Render thread cycles.

As a general rule, highlighted especially by the ProgressBar, you should always make sure to stop animations (not pause) and remove / collapse animating controls when they’re no longer needed.

Remember: just because you can’t see a animation / control doesn’t mean that it isn’t there doing work.

WP7 Perf Tip #1: Test on Device

August 24th, 2010 Oren No comments

I’m kicking off a series of posts about Silverlight perfofmance under Windows Phone 7 with a a kind of obvious one, but one that is important to keep in mind from the get go.

Tip:

  • Test your code on device as much as possible

But the Emulator is awesome?!?

True, the emulator, otherwise known as the x86 Device Emulator, or simply XDE, is awesome, but it is still not an accurate representation of a device. In fact since the XDE is usually so smooth, it’s extremely easy to fall into the trap of adding more features “because it works on the emulator”.

The Hardware

The emulator restricts itself to one core, adds artificial Sleep()’s and limits the amount of memory it is happy to eat up (so it won’t just chew through whatever is available), but that still isn’t enough.Chances are that even running at one core the emulator is still running faster than the device (most cores today are going to be running faster than 1GHz and chances are you are going to have less things running on that core than the device does). Throw in a desktop GPU which beat a mobile GPU handsdown and you’ve got a winning combination. If you happen to have an older machine, then the XDE will simply run like a dog – and you won’t be able to tell if your app crawls because of your code or because of your machine.

But I don’t have a device!

Common problem, especially in these trying, pre-release, times. Fear not though! Your local Microsoft office most likely has some devices and can help hook you up. Shoot them an email and let them know that you are working on an app, include a description and some screenshots from the XDE (to sweeten the deal) and they should be able to help.

BUG: Silverlight Crashes (Along With the Browser) When Profiled

August 5th, 2010 Oren No comments

It’s one of those bugs… If you’ve tried profiling Silverlight lately and you’ve run into a consistent crash in Silverlight which brings down the browser, but only on specific projects then this bug is for you.

Basically, profiling any Silverlight app (plugin or OOB) that takes advantage of Shaders will cause Silverlight (and its container) to crash. The only current workaround is to remove the shaders before profiling (possibly with an #ifdef if you are so inclined). This is slated to be fixed in an upcoming version of SL 4 (though no release dates yet).

Note: people often get scared of crashes since they can indicate a security bug – but this is not a security issue (the profiler puts us into a bad state, causing the crash).

Cross-posted from msdn.

Categories: Performance, Silverlight Tags:

System Tray obscures FrameRate counters

June 28th, 2010 Oren No comments

Here’s a small tip for those of you who want to debug performance in a Windows Phone Silverlight app with the frame rate counters, but have the System Tray visible – hide it.

The counters currently show up behind the system tray (since technically the tray is a system overlay which is drawing over the surface available to your Silverlight app), so hiding the tray will show the counters.

Don’t forget: to re-enable the system tray when you’re done!

Media on Windows Phone 7: “Content” Ye Shall Be

May 10th, 2010 Oren No comments

Here’s an awesome gotcha when moving from a desktop Silverlight application to a Windows Phone 7 application – make sure that your media (wmv) files are set to “Build Action” = “Content” and not “Resource”.

You’ll notice that if you do something like:

<MediaElement Source="somevideo.wmv"/>

Where “somevideo.wmv” is set to “Content”, then the Windows Phone Developer Tools (ie. Visual Studio) will underline the "Source" attribute and recommend that you set it to “Resource”. This is a hangover from the desktop and is something that I hope will go away – you can safely ignore this warning (it won’t appear in your build windows).

What’s Wrong With “Resource”?

For those that want more, here are the potential problems you can run into when setting your media to “Resource”:

  1. When a video file is compiled as a Resource it incurs an extra space and performance hit every time you play it, since Silverlight does extra processing to extract the video from your assembly (DLL). In the case of “Content” the file can be read directly from disk (or memory) and you’ll get instant start playback.
  2. Anything that makes your DLL larger is evil (from my point of view) – you want your assemblies to be small (think “quick and nimble”). Although the size doesn’t always directly affect load and memory time (there are a couple of other factors at play here) this helps eliminate one more possible bottleneck.