add new issue       

Issue ID:  550     Rework MethodCaller to use lambda expressions for performance      
Created by rocky on 2009-09-01 10:33 AM, 3006 days ago
Project:  CSLA .NET for Silverlight
Category:  enhancement
Priority:  high
Status:  closed
Feature area:Reflection
  Entering "issue#999" in comment creates link to id 999

show inline images      show change history

comment 2248 posted by justinc on 2010-03-03 2:19 AM, 2823 days ago 
Fields are now accessed by lambda expressions. However this was a little tricky to implement because MethodCaller does not expose any mechanism for calling fields. The DataMapper does but it's pretty limited. You should consider consolidating the property/field factories into a single method. The two could be built as if they were the same.
comment 2192 posted by justinc on 2010-02-18 5:51 PM, 2836 days ago 
Actually looking at this, there is still some ILGeneration code for field accessing (which never happens in SL) but it would be nice to unify this before closing completely.
comment 2190 posted by justinc on 2010-02-18 5:36 PM, 2836 days ago 
I believe this one is done now, with your last two changes.
comment 2188 posted by rocky on 2010-02-18 5:20 PM, 2836 days ago 
Added type name rewriting to MethodCaller.GetType() for Silverlight, so it has the functionality from SL3.
comment 2187 posted by rocky on 2010-02-18 5:19 PM, 2836 days ago 
Removed the #if blocks in MethodCaller so SL now uses nonpublic members when necessary.
comment 2145 posted by justinc on 2010-02-05 11:12 AM, 2849 days ago 
THis is mostly done but there is one issue remaining where BindingFlags.NonPublic was not added for Silverlight. This seemed like a good idea but actually it's possible in some cases for silvelright to invoke non public members via reflection (e.g. the member is declared in the same type it's invoked from.
comment 2054 posted by justinc on 2010-01-21 8:35 PM, 2864 days ago 
Actually it looks like the DynamicMethodHandlerFactory in the .net version is pretty well segmented already. I should probably just use replace the body of that with linq expressions to build the delegates. This will make it easier to maintain and will allow Silverlight to use the same code.
comment 2052 posted by justinc on 2010-01-21 5:28 PM, 2864 days ago 
It should be possible in both in .net4 using linq expressions to generate delegates. The general strategy will be to use the current method to find the method to invoke then to build lambda expression that sort of looks like one of the two following forms: // this is a call to a method with a return type of void. Func f1 = parameters => { method((int)parameters[0], (string)parameters[1], ...); return null; } // This is a call to a method with a non-void return type. Func f2 = (parameters) => { return method((int)parameters[0], (string)parameters[1], ...); } Using these two types of functions it allows the MethodCaller to cache calls into a Dictionary>> and call them in a standardized fashion. It turns out that calling Delegate.Invoke() is much much slower than using pure reflection but if you can create a strongly typed delegate than it is much faster to build the expression and cache it than to use pure reflection.
comment 2049 posted by rocky on 2010-01-20 5:50 PM, 2865 days ago 
merged bug 684 into this bug:
MethodCaller is able to invoke invalid method overloads
comment 2047 posted by rocky on 2010-01-20 5:49 PM, 2865 days ago 
Justin, maybe this can be resolved by changing MethodCaller to use expression trees instead of dynamic method invocation?

Solution needs to work on .NET and SL (ideally MethodCaller.cs would be a linked file :) )
comment 2010 posted by rocky on 2010-01-14 10:59 AM, 2871 days ago