Performance diff between Target=“someType” and Tar

Question

Possible Duplicate:
Difference between TargetType=“controlType” and TargetType=“{x:Type controlType}”
when to use {x:Type …}?

At Difference between TargetType="controlType" and TargetType="{x:Type controlType}" I can see that these different methods of setting type are basically the same. But I was wondering if there are any performance implications since I guess {x:Type} will instantiate a markup object.

Answer 1

As Jon pointed out, in both cases a "converter" is used to return a Type based on a string.

When using x:Type, it's actually using a TypeExtension. If you look at this code in Reflector, you can see it basically does:

IXamlTypeResolver service = serviceProvider.GetService(typeof(IXamlTypeResolver)) as IXamlTypeResolver;
return service.Resolve(<<"typenamehere">>);

When you simply pass a string value (i.e. you don't use x:Type), then a type converter is used. In this case, since the target property is Type the converter used is TypeTypeConverter.

If you look at the ConvertFrom method of TypeTypeConverter, you will see it performs an identical operation as TypeExtension.

Therefore, the string to Type conversion code is identical. So the only difference would be in the instantiation of the TypeExtension versus TypeTypeConverter.

It appears in either case a new instance is created as needed, but it would be more likely for the framework to reuse a TypeTypeConverter. This could also be a future optimization, but probably not a likely.

Either way, I doubt you'd notice any sort of performance improvement using one method or the other.

Answer 2

Talking about performance here is missing the woods for the trees.

If you use a string value, WPF will use a value converter to turn that into a Type object; otherwise it will use a markup extension. In both cases, a naive implementation would create an extra object. Therefore I don't see how any of the two cases could be assumed to created fewer objects than the other.

It's quite possible (one would need to check the MS sources to confirm) that .NET caches and reuses singleton instances of these classes because they are known to be stateless.

Therefore I believe that performance considerations are totally out of place in this scenario. My opinion is that it's better to use {x:Type} because it's clear just from the XAML what kind of value is produced.

Answer 3

I'd suggest that creating one fewer object is going to be beneficial to performance. However, in this case, the performance gain may be so small that you're better off considering readability of your code instead.

I always use {x:Type someType} as it makes it clear that here is a type I am talking about.

And when I change things later on, I can always search on {x:Type.

Answer 4

Worth noting that neither TypeConverter nor MarkupExtension is used in case of providing a type name as string.

As per MSDN -

Type Properties That Support Typename-as-String

WPF supports techniques that enable specifying the value of some properties of type Type without requiring an x:Type markup extension usage. Instead, you can specify the value as a string that names the type. Examples of this are ControlTemplate.TargetType and Style.TargetType. Support for this behavior is not provided through either type converters or markup extensions. Instead, this is a deferral behavior implemented through FrameworkElementFactory.

http://msdn.microsoft.com/en-us/library/ms753322.aspx