This document discusses various techniques for optimizing the performance of the WPF/XamDataGrid control. It covers optimizing application resources, layouts and templates, data binding, converters vs data template selectors, UI virtualization, themes and styles, real-time updates, and initial loading time through preloading and NGEN. Specific recommendations include reducing visual elements, using virtualized containers, fixing binding errors, binding to collections rather than individual properties, and using UI virtualization modes to improve scrolling performance over large datasets.
2. Contents
• Application Resources
• Layouts & Templates
• Data Binding
• Converter vs. DataTemplateSelector
• XamDataGrid-specific optimizations
– UI Virtualization
– Themes and styles
– Real-time updates
• Initial Loading Time (preloading and NGEN)
3. Application Resources
• Load relevant resources at the view level
(as opposed to on the application level)
• Use shared resource definitions on the
Window/Application level
• Use static resources rather than dynamic
ones to save on lookups at runtime
4. Layouts & Templates
• Reduce the number of visual elements
• Use virtualized container with recycling
• Refrain from using BitmapEffects
• Set the neutral culture using
NeutralResourcesLanguageAttribute to
prevent lookup of satellite assemblies
5. Data Binding
• Fix binding errors to prevent expensive
binding path resolutions
• Binding to many properties of an object is
expensive compared to binding to few
properties of many objects
• Test with 1000 textboxes
– Bound to 1 object’s 1000 properties – 950ms
– Bound to 1000 objects 1 property – 115ms
6. Data Binding
• Bind to IList rather than
IEnumerable, because the CLR generates
an IList to wrap it
• For adding/removing data from data
sources, bind to ObservableCollection<T>
rather than IList
7. Convertor vs DataTemplateSelector
• Use Convertors instead of
DataTemplateSelectors
– Added flexibility in specifying business logic
– Slightly better performance
• For virtualized control, the convertors will
be invoked for each cell coming into view,
• Apply processing in code-behind and bind
to transformed/formatted data
8. Convertor Limitations
• For virtualized item controls, the
conversion logic will be invoked for each
cell coming into view
• Avoid unbound columns and convertors -
apply processing in code-behind and bind
to transformed data
• Apply formatting using styles rather than
converters, e.g. date or time formatting
9. XamDataGrid UI Virtualization
• XamDataGrid supports virtualization
modes on the row and column level to
help you adjust performance for your
specific scenarios
• You can customize the virtualization
setting using the
RecordContainerGenerationMode and
CellContainerGenerationMode properties
10. XamDataGrid Virtualization Modes
• Recycle
– Reuses the same visual elements, binding
them to data items as they are scrolled into
view
– Minimize space requirement at the expense of
time
– Suitable for high-volume data scenarios with
simple UI controls in the cells
11. XamDataGrid Virtualization Modes
• PreLoad
– Initialize visual elements to represent the
entire dataset
– Improve runtime performance at the expense
of space and startup time
– Useful when you require smooth scrolling
over a relatively small dataset, and you have
user controls hosted in the control with
expensive initialization/formatting applied
12. XamDataGrid Virtualization Modes
• LazyLoad
– Initialize visual elements to represent the visible
dataset, adding new ones to represent data
subsequently brought into view
– Minimum space at startup, increasing space
footprint, accessing cells that have been in view
is fast
– Useful when you require smooth scrolling over a
relatively small dataset, and you have user
controls hosted in the control with expensive
initialization/formatting applied
13. XamDataGrid Event Suppress
• Suppress unused routed events to
improves performance due to the
overhead incurred with routed events in
element hierarchies.
• There are also direct CLR events added
for common routed events on the
DataPresenterBase.
14. XamDataGrid Themes & Styles
• Set the Theme property to prevent
overhead in template lookup
– Implications for preloading
• Use a hover-less theme to prevent row
highlighting on mouse hover
15. XamDataGrid Real-Time Updates
• Using INotifyPropertyChanged on the
property level (usual MVVM setup)
– Useful for sparse updates, good for most cases
– One event updates one bound column
• Using INotifyPropertyChanged on the row
level
– Useful for scenarios where all the properties in a
row are changed. This updates the entire row
using a single property changed notification,
instead of raising N property changed events
– One event updates an entire row
16. XamDataGrid Real-Time Updates
• Using CollectionChanged.Reset for
frequent and extensive data updates
– Useful for scenarios where the underlying
datasource changes dramatically – e.g. a new
batch of rows come in from a backend system
– One event updates the entire grid
17. XamDataGrid ReadOnly Style
• Using the read-only cell style (provided on
my blog), you can get a radically simpler
CellValuePresenter style, which improves
performance
• It does not render editors for cells in edit
mode,
• Setting EditAsType the same type for all
XamDataGrid fields facilitates cell
virtualization
18. Initial Loading Time - Preloading
• Preloading XamDataGrid (and any other
Infragistics controls) in a window not
shown to the user pays upfront the cost of
JIT-compiling the XamDataGrid
• This causes user-initiated opening of a
window containing the XamDataGrid to be
much faster
• Approach is described here
19. Initial Loading Time - NGEN
• The JIT compiler compiles methods as
required during execution
– Takes up CPU time
– Compiled code cannot be shared among
processes
20. Initial Loading Time - NGEN
• Using NGEN to create pre-compiled (native)
images of Infragistics DLLs to eliminate JIT-
compilation
– Reduces the memory footprint
• JIT compiler does not need to be loaded in memory)
• Native images can be shared among processes
– Improves loading time in warm startup scenarios
Note: NGEN’ed assemblies need to be in the
GAC on the client machine in order to avoid
costly strong-name validation procedure.