WPF: Tips - Too Much Measuring Up Is Bad
This article tries to explain plainly why and how you can over work your processor with auto sizing. The usual explanation of Measure Arrange is a bit mind numbing. The point can easily be lost amongst the details of the explanation. This article tries to get the important stuff across in a digestible manner.
A common piece of advice for wood working is "Measure three times, cut once" well in WPF it's different.
No wood?
Your alternatives can sometimes be to let something measure many times or force it to do so just once.
Layout Flows
WPF is designed to allow contents to flow in a way which is like HTML rather than the fixed position and size of everything that desktop developers might be more used to from other technologies.
The resultant flexibility of layout is great for things like localisation where 12 characters in one language can be 30 in another. Similarly where content is managed by a user, widely differing sized articles can be presented by the same set of controls without any extra coding.
XAML's layout flexibility can come at a price which is not immediately obvious and can even be crippling in certain situations.
You may have heard of the old piece of advice when doing DIY job and you're about to cut a piece of wood.
"Measure three times, cut once."
Well in WPF a complicated layout can involve an awful lot more than measuring things three times if you're not careful.
The Short Story
You often want to avoid using auto sizing on columns of an ItemsControl such as a DataGrid.
If you let those columns work out what size to use then you can introduce a LOT of processing overhead.
Use the * mechanism and or fixed widths instead of Auto.
Measure Arrange
The problem is the way Measure Arrange works - see the Measuring and Arranging Children section here for a more complete explanation.
When you have some sort of panel or container which is sizing itself to it's contents then it has to somehow decide what that size is going to be.
Each of it's children decide how big they would like to be. They pass it up the tree - they ask their container if they can have that DesiredSize.
The container checks them all out and sees what size they can have.
It then arranges it's children within itself.
It is this process which is involved in making something fill it's container by default and a container fit it's contents if it is auto sized - like say a stackpanel.
Auto width Columns of Auto Height Rows in a Grid also count, in case you were hoping use of the word container precluded them.
Rows x Columns = Lots = Bad
This shuffling about as controls grab space is fine if there are only a few of them. Just a few won't take a noticeable time.
If you have a number of columns, each of which has a number of controls per row then this is when the really big overheads kick in.
Particularly with a control like a datagrid which often has a fairly complicated structure to it.
If everything is auto sized then each value is read into it's particular control - usually a textblock. That demands some space which asks it's container for space.
There are a surprising number of layers per cell. Each demands space of it's parent.
This is repeated for every row in a column.
Then each column might vie for space with other columns.
All this means absolutely everything is measured up and moved about numerous times.
Before you know it, your DataGrid is sat there seemingly doing nothing for a significant and painfully noticeable time.
As you scroll more data into view it's sluggish and maybe even jumpy.
What's worse your users then phone up and complain.
See Also
This article is part of the WPF Tips Series, if WPF is your area of interest then you will probably find other useful articles there.