I don't have a test or benchmark to prove it, but reasoning as follows suggests that the visual-states approach should be faster by far.
For the binding scenario:
- Each binding from the view causes an event handler to be triggered, each time
PropertyChanged
is raised. - Each one of these handlers must be executed every time any view model property changes.
- Similarly, when you change view model properties to in order to update a view's configuration, all the handlers must be run for each property you change.
The visual state scenario has none of these handlers to churn through:
- The VisualStateManager has no handlers, so it does not consume any CPU when it is not needed (it ignores "PropertyChanged", or in the worst case, has only one listener attached to a "CurrentState" property).
- To trigger a visual state only requires the attached Storyboard to be run -- PropertyChanged does not get raised (except maybe once, at most, as per above), and so all the handlers do not need to run multiple times.
It seems clearly better for performance to use Visual State Manager, than to set up an excess of view-to-viewmodel bindings.
Edit John Gossman also noted (a long time ago) that bindings can be heavy, and can start consuming excess memory in large applications. In the linked article, he claims to have saved 100MB by replacing all bindings with a single static callback.