[Mono-dev] Fast variant type cast
kumpera at gmail.com
Fri Sep 24 18:21:19 EDT 2010
Hey Mark and Paolo,
I've speed some time looking into speeding up variant type cast as one can
expect it to be used a lot more with 4.0
since a lot of central types have been made variant.
I first looked into making a managed version of the casting code for variant
types but this is incredibly hard, to say the least,
due to 2 issues, it has to inspect the instantiation vector of the target
type (which is made of MonoType values) and it has
to iterate thru all interfaces of a given type.
It is not impossible, but it's a lot work and probably quite some extra
memory to make it fast.
So I decided to avoid the whole problem and go with adding an one entry
cache in front of the casting op. It's significantly faster
when the hit ratio is high and the cache test could be inlined for extra
performance (right now it's an icall).
I got this working on on this branch of github:
Then I went into checking real world usefulness and found out that this
change does no good at all. At least with the benchmarks
IronPython does a constant number of casting operations, so it's not usable.
The test suites of corlib and sys.core revealed one critical bug with my
approach, it doesn't handle the case where it's not
possible to statically known if we're handling with a generic variant type
or not. And this is 99.999% of all casts to variant types
on those tests.
So this left me with two options. Make mono_object_isinst faster with
variant types or look into caching all casts ops
I'll try enabling caching for all gshared cast ops first, then into making
mono_object_isinst faster if needed. How to do
it still an open problem but looks easy for types without nested variance -
not IEnumerable<Func<string,string>> for example.
I tried to enable caching for all gshared casts but I'm bumping into a
runtime crash in the innards of the gsharing code.
Any advices, tips or a code review of the mentioned branch?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list