WPF MVVM中非UI线程调用OnPropertyChanged致性能下降，求优化原理

Great question—this is a super common pitfall with WPF's threading model, so let's break down exactly what was happening and why your fix made such a difference.

First, WPF's Non-Negotiable Thread Rule #

WPF operates on a Single-Threaded Apartment (STA) model for all UI-related work. In plain terms:

• All UI elements, data binding updates, and property change notifications that trigger UI refreshes must run on the UI thread.
• When you fire OnPropertyChanged from a non-UI thread, WPF can't process the notification directly—it has to jump through expensive hoops to get that message to the correct thread.

What Was Causing the Slow UI Updates? #

When you called OnPropertyChanged from a background thread:

1. Thread Context Switch Overhead: WPF automatically tries to dispatch the property change notification to the UI thread using Dispatcher.BeginInvoke (or similar). Every context switch between threads is surprisingly costly—especially if MyDate was updating frequently. Multiply that by two (since you notify both MyDate and MyDateFormatted), and the overhead adds up fast.
2. Dispatcher Queue Congestion: Frequent cross-thread dispatch requests pile up in the UI thread's dispatcher queue. The UI thread would spend more time processing these queued requests than actually updating the interface, leading to laggy, delayed UI refreshes.
3. Delayed Computed Property Evaluation: MyDateFormatted relies on _myDate to generate its value. When the notification came from a non-UI thread, WPF had to wait for the dispatch to complete before re-evaluating the property, adding extra latency to the UI update.

Why Moving OnPropertyChanged to the UI Thread Fixes It #

By ensuring OnPropertyChanged runs on the UI thread:

• No More Context Switches: The property change notification is handled directly on the UI thread, eliminating the expensive cross-thread dispatch step entirely.
• Immediate UI Updates: The binding system processes the notification synchronously and updates the UI right away, no waiting for a slot in the dispatcher queue.
• Efficient Computed Property Handling: MyDateFormatted is re-evaluated immediately when the notification fires, so the UI gets the updated value without any unnecessary delay.

Quick Example of the Fix (For Context) #

If you were previously updating MyDate on a background thread, your fix would look something like this—marshaling the property update to the UI thread:

// Background thread code
Application.Current.Dispatcher.Invoke(() => 
{
    MyDate = DateTime.Now; // Triggers OnPropertyChanged directly on the UI thread
});

This keeps all property change logic on the correct thread, wiping out the overhead that was dragging down your app's performance.

内容的提问来源于stack exchange，提问作者Cod Fish