WPF Singleton ValueConverters performance implications

Question

I have been consistently using Singleton value converters in WPF. But recently I got into an argument with a colleague where he was saying like it is bad to use singleton instance of valueconverters as they would be disposed only by the app domain unload. He was suggesting that singleton converters may come handy only in case of a page which is kept loaded until an application unload. Would really like to know views of WPF experts here.

EDIT (with example): I have a converter like

public class ABCConverter : IMultiValueConverter
{
    private static ABCConverter _instance;

    public static ABCConverter Instance
    {
        get { return _instance ?? (_instance = new ABCConverter()); }
    }

    public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
    {
        return true;
    }

    public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
    {
        return false;
    }
}

I presently use it in xaml as

Converter="{x:Static conv:ABCConverter.Instance}"

Thanks in advance.

Raj

Please provide a code example to help improve the question. – Dec 23 '13 at 06:58 — , Dec 23 '13 at 06:58
Thanks Trevor! Added example code. – user3128579 Dec 23 '13 at 07:28 — user3128579, Dec 23 '13 at 07:28

score 2 · Accepted Answer · answered Dec 23 '13 at 06:47

2

What you are arguing over here is a micro-optimisation. Unless your value converter is quite massive, the memory it consumes will be quite small.

Do not optimize prematurely. The 'standard' pattern for value converters is to create a new instance within each binding, i.e. avoiding singletons. If you do find yourself encountering memory issues, optimize at that point. Use profiling tools to determine where the issue is and target them specifically. I am willing to bet that your value converter will not be teh root cause of a memory issue.

answered Dec 23 '13 at 06:47

ColinE

68,894
15
164
232

When I carried out profiling (using ANTS+), I found out that a particular ValueConverter had almost 12 instances in memory. Then only I moved into a Singleton pattern of value converter usage. As you said, the memory used was just 12 x 40 = 480b, but still it was for a single Value Converter type. But after getting into conversation with my colleague, I too got into a state of confusion. – user3128579 Dec 23 '13 at 06:54
12 instances, thats not many at all - 480b is minuscule! Go for th simplest option. Remove the singleton! – ColinE Dec 23 '13 at 06:56

score 0 · Answer 2 · answered Dec 23 '13 at 06:49

0

I my point of view, it is recommended to have value converters as Singleton since the converters might not have any local values and its just convert the values as desired values.

answered Dec 23 '13 at 06:49

Sankarann

2,625
4
22
59

Mark Feldman · Answer 3 · 2013-12-23T06:57:35.997

0

There's no clear answer to this, it depends on your specific circumstances. If you're using a proper dependency injection framework (i.e. Ninject, Unity etc) then you can create an object in singleton scope without actually creating a singleton, you can even scope the converters to the life of particular object e.g. a parent window. Another thing you might want to look into is weak references, you get the performance benefits of a singleton but they get periodically cleaned up during routine GC if the app needs more memory.

edited Dec 23 '13 at 06:57

answered Dec 23 '13 at 06:51

Mark Feldman

15,731
3
31
58

And how to instantiate ValueConverter from a Container? ValueConverters are specified in Xaml. – Luka Oct 28 '19 at 11:11

WPF Singleton ValueConverters performance implications

3 Answers3