WPF Dictionary Binding failure is very slow

Question

I have most of the Label objects in my app bound such that they can be replaced from a webservice.

I store my replacements in a Dictionary. The repla

Answer 1

If you have the option to, I would change your IDictionary implementation to one that returns null and instead use TargetNullValue (or even be IDictionary<TKey, object> and return DependencyProperty.UnsetValue if you still use FallbackValue):

public class PassthruDictionary<TKey, TValue> : IDictionary<TKey, TValue>
{
    private Dictionary<TKey, TValue> instance;

    // ... other stuff

    public TValue this[TKey key]
    {
        get
        {
            TValue value;
            if (instance.TryGetValue(key, out value))
            {
                return value;
            }
            else
            {
                return default(TValue);
            }
        }
        // ... more
    }
}

Answer 2

EDIT:

Actually, all this does is disable the output in the VS output pane. It doesn't actually speed things up.

ORIGINAL:

I had a similar problem, but I wanted to catch and log the errors. However, you can use the following solution to simply disable outputting the errors to the VS2010 output window. The solution comes in 2 parts, the first is a simple class:

using System.Diagnostics;

namespace DevBindingErrors
{
    /// <summary>
    /// Intercepts all binding error messages. Stops output appearing in VS2010 debug window.
    /// </summary>
    class BindingTraceListener: TraceListener
    {
        private string _messageType;

        public override void Write(string message)
        {
            // Always happens in 2 stages: first stage writes "System.Windows.Data Error: 40 :" or similar.
            _messageType = message;
        }

        public override void WriteLine(string message)
        {
            Debug.WriteLine(string.Format("{0}{1}", _messageType, message));
        }
    }
}

The 2nd part is in App.xaml.cs:

using System.Diagnostics;
using System.Windows;

namespace DevBindingErrors
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        public App()
        {
            PresentationTraceSources.Refresh();
            PresentationTraceSources.DataBindingSource.Listeners.Add(new BindingTraceListener());
            PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Warning;
        }
    }
}

If you want to ignore all binding errors, just comment out the Debug.WriteLine(...) line. (I wouldn't really recommend this though) This will speed up execution as well, without losing the ability to debug the application.

The idea for this solution came from this page, which has more details on trace sources in WPF too.

Answer 3

Yes, the speed can be improved dramatically if you do not run the code in a debugger. Actually the printing of the stackteace in Visual Studio is by far the slowest part. If you run your application without a debugger attached, I am pretty sure the performance loss will not be noticable anymore.

I had a similar problem where we were catching an exception inside a library and even if you do that VS will print a note about a first chance exception being caught in code, every time the exception is being caught (and handled). The exception was triggered about 50 times at the startup and it took the application like 10 seconds to startup and all just because of the console logging. Once I ran the application without a debugger it started up almost instantly.

So maybe trying to workaround that exception is just premature optimization.