I find my self in possession of a bunch of Expression<Func<double,double>>,
e.g. foot = meter => meter * 0.3048, which I'd like to use as interceptors.
So now my interceptor looks like
public void Intercept(IInvocation invocation)
{
Expression<Func<double, double>> e = m => m * 0.3048;
var f = e.Compile();
// f would really have been calculated previously
// now execute the function, though we're doing boxing and
// delegate invocation for what amounts to
// a simple math expression
double x = (double)invocation.GetArgumentValue(0);
invocation.SetArgumentValue(0, f(x));
}
While many applications of injection involve reasonably expensive operations
like caching and logging, in my case these expressions are so simple that
the overhead of argument boxing and delegate invocation is likely to be
extremely large compared to the work done.
What I'd rather do is something like specify interceptors using these
expressions directly. (I assume by being sufficiently clever with the
IInterceptorSelector I can avoid having to switch on MethodInfo to know
which transformation to apply in each interceptor.) Perhaps my proxy
creation could look like this (looking at the things an IInterceptorSelector
does)
var proxy = generator.CreateInterfaceProxyWithTarget<T>(
@object,
(type,method,interceptors) => /* inspection determines we want the transform
to look like: */ m => m * 0.3048);
While there are some other sophisticated things that interceptors can do,
this would satisfy several interesting use cases where your're just
transforming function arguments. Then instead of using Reflection.Emit to
generate a fast call to the IIntercept.Intercept function (which has to do
the boxing, unboxing, etc.), you could compile the Expression itself right
to a method and inline it directly into the generated stub method. In an
ideal case, this means that the multiplication mentioned above would end up
being inlined.
(There would likely need to be some conventions for specifying you want to
transform parameters vs transform return values, etc,)
With .NET 4.0 you might be able to compile the Expression directly to IL via
CompileToMethod and call it, though there might even have to be some
trickery with generated static functions on the proxy object, see
http://www.justinmchase.com/post/2009/08/01/LambdaExpressionCompileToMethod-e280a6-not-nearly-as-cool-as-I-had-hoped.aspx.
This would allow dramatically simple transformations (like the above
multiplication) to be inlined by the JIT.
Staying with .NET 3.5, you could still use .Compile to compile the
expression to a delegate which would be invoked, but you should be able to
avoid the argument boxing with some work.
I have just started working with Castle and may well be barking up the wrong
tree!
Many thanks.
--
*Sebastian Good*
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
