In this great WPF performance session, Bart De Smet and Eric Harding have talked about WPF performance and demonstrates some of the performance tools the WPF team uses.
One of the important things to do regards performance is to start measure early. Perceived performance, make it feel fast, turn it to an art and not a science. There would be trade offs – CPU versus memory, etc.
Memory
New WPF application called FishBowl has been announced. It’s a small application dealing with facebook as a case study.
To profile memory do:
Cold Start
To profile cold start do:
- Prevent unnecessary DLLs from being loaded
- Set xperf to run at startup – this shows how much CPU by process also disk IO
- Use .NET memory profiler again to know what object was loaded
Warm Start
To profile warm start do:
- Run the application
- Use WPF Perf Visual Profiler, and attach to application to analyze the visual tree (how many elements loaded)
- Use CPU profile such in Visual Studio Profiler to look for the hot path with higher CPU time
Runtime
To profile runtime do:
- Use WPF Perf Visual Profiler to see were CPU spend its time
- Use perforator to see rendering performance
- High IRTs (GPU) may effect frame rate – effects, clips, opacity and opacity mask
- Element count may increase IRTs – input and routed events
- In .NET 4.0 here is a Cache Composition trading video memory with CPU

Runtime Best Practice
- Don’t block UI thread
- Use UI Virtualization and Data Virtualization when possible
- Freeze your freezables – no change notification callbacks
- Hardware vs Software
- RDP, virtual machines, old hardware
- RenderCapability.Tier
- Reduce frame rate, 3D rendering

This is it for this session. In a future post I’ll describe this process in more details.