tags:

views:

715

answers:

2

Hi all. In an application that I have, I am doing quite frequent calls to Convert.ChangeType in order to convert a value to a dynamically loaded type.

However, after profiling with ANTS, I've found that this Convert.ChangeType seems to take a significant portion of time (due to being called quite often). Does anyone have a faster alternative to doing this?

At this point I have a type object containing the target, and a string containing the value.

The following is the offending code. I was considering doing a switch-statement on type (since it is a limited collection of types) and calling the parse methods, though I'm not sure whether or not that'll be faster.

if(attributeRow["Value"]!=DBNull.Value)
    sample[attr] = attr.AttributeType == typeof(Guid)
                 ? new Guid(attributeRow["Value"].ToString())
                 : (IComparable)Convert.ChangeType(attributeRow["Value"],attr.AttributeType);
A: 

You could roll your own 'ChangeType' functino that just does static C-style casting. That would be my approach.

Mark P Neyer
The problem is that the source is a string, not an actual value, thus Casting wouldn't work I'd suspect.
Erich
A: 

I'm not aware of any other functionality within the framework itself for changing Types other than the Convert.ChangeType function (and explicit casts, obviously).

For this, I think the only other way to improve this is to roll your own ChangeType function that is specifically optimized for your particular situation (if possible).

You mention that you're working with a limited number of Types, perhaps you're dealing with one Type more than the others? Is so, your ChangeType function could be optimized to attempt this specific conversion first, and only trying others if failing. You mention trying a switch-style block of code, and this same approach (trying the most frequently used Type first) could be applied to that. As to whether it will be faster would depend upon your data that you're processing (and the frequency/variability of the Types you're converting to/from) and the only real way to measure this is to try it and profile it in comparison with the Convert.ChangeType methodology.

One interesting link if you're looking to roll-your-own functionality is on Peter Johnson's blog:

Convert.ChangeType doesn't handle nullables

Be sure to read all of the comments to the post also.

CraigTP
We're going to look into a few things, but this post confirms my fear that we were doing it the best way possible, so I'm accepting this answer.
Erich