[Mono-bugs] [Bug 79074][Wis] Changed - Mono places remoting calls for System.Object method

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lluis at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=79074

--- shadow/79074	2006-08-14 18:27:38.000000000 -0400
+++ shadow/79074.tmp.21444	2006-08-14 20:14:20.000000000 -0400
@@ -2,13 +2,13 @@
 Product: Mono: Runtime
 Version: 1.1
 OS: All
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Wishlist
 Component: remoting
 AssignedTo: lluis at ximian.com                            
 ReportedBy: brian at fluggo.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -71,6 +71,49 @@
 scenario. In the above scenario, the framework can return false without
 placing the call.
 
 Additional Information:
 This bug could be a source of the performance problems that inspired the
 fast-xappdomain paths.
+
+------- Additional Comments From lluis at ximian.com  2006-08-14 20:14 -------
+> Calls to Equals across domains is substantially slower than 
+> calls to a local (non-MarshalByRefObject) object.
+
+This is also true for MS .NET, just try to run the above test case.
+
+> Calls to Equals, when it's not overridden, should be just as
+> fast in either scenario. In the above scenario, the framework
+> can return false without placing the call.
+
+It's not so simple. Some special checks would need to be added when
+creating the proxy and the method wrappers. The method call will never
+be as fast as a normal call since you don't have a real object in the
+calling domain, but a proxy. 
+
+At the end, what matters is performance. If you compare the performace
+you'll see that we aren't doing bad. Mono is much faster than MS.NET
+1.1 when calling Equals(null) through the cross app domain, and a bit
+slower that MS.NET 2.0.
+
+> This bug could be a source of the performance problems
+> that inspired the fast-xappdomain paths.
+
+Nope. I implemented the fast cross appdomain path to optimize the
+following cases:
+1) When there are no custom remoting sinks registered, we can avoid
+the remoting sink chain. It means avoid converting the call into an
+IMessage object, go through the sinks, and convert the IMessage into a
+call in the remote domain.
+2) When all the parameters of the call are primitive types. In this
+case the xdomain fast path can make a value copy of the parameters and
+there is no need to use the binary serializer.
+
+For example, in the case of XSP the most critical remote call is
+ProcessRequest, which happens to satisfy both conditions, so those
+calls take full advantage of the complete xdomain fast path.
+
+However, if the target assembly in the remote domain has been loaded
+from a different location (which may happen after aplying the patch
+for #76757), the fast path can't be used because types can't be
+shared, so it has to go through the complete remoting sink.
+