Elapsed Time (ms) | Ops Per Second | |
Method in same class | 1982 | 201,816,347 |
Class in same assembly | 2994 | 133,600,534 |
Class in another assembly (DLL assembly, loaded in calling process) | 2263 | 176,756,518 |
Class loaded from another AppDomain in same process (Serializable) 2 | 1922 | 208,116,545 |
Class loaded into another AppDomain in same process (MarshalByRef) | 59345 | 6,740 |
P-Invoke unmanaged c++ DLL | 14741 | 2,713,520 |
COM Interop - inprocess DLL (STA caller, STA object) | 29622 | 1,350,348 |
COM Interop - inprocess DLL (MTA caller, STA object) | 3294 | 12,143 |
COM Interop - .NET COM+ object (ServicedComponent) library package, transaction disabled | 14220 | 7,032,349 |
COM Interop - .NET COM+ object (ServicedComponent) library package, transaction required | 3404 | 2,938 |
COM Interop - .NET COM+ object (ServicedComponent) 1 server package, transaction disabled | 13549 | 1,476 |
COM Interop - .NET COM+ object (ServicedComponent) server package, transaction required | 10014 | 999 |
Remoting - local server, Serializable, HTTP | 2233 | 179,131,214 |
Remoting - local server, Serializable, TCP | 2233 | 179,131,214 |
Remoting - local server, MarshalByRef, HTTP | 26968 | 148 |
Remoting - local server, MarshalByRef, TCP | 4266 | 938 |
Remoting - remote server, Serializable, HTTP | 3034 | 131,839,156 |
Remoting - remote server, Serializable, TCP | 3084 | 129,701,686 |
Remoting - remote server, MarshalByRef, HTTP | 12728 | 79 |
Remoting - remote server, MarshalByRef, TCP | 4246 | 236 |
1 - When using COM+ package with "server" activation, the results between "transaction required" and "transaction disabled" are very similar. This must be due to the slowest part of the call is the server activation -- not the existence of transaction or not. See the difference between transaction attributes in the library activation setting a couple lines above.
2 - Why is this so much faster? Loading a class that is serializable from another AppDomain marshals the object over to the calling AppDomain, and should be the same speed as "local class". There must be something else going on here...
AppDomains
Creating a type in another AppDomain is really very simple - especially in this case where the type is in the currently executing assembly.
// they say CreateInstanceAndUnwrap needs fully qualified name,
// but after all the trouble, the "name" only is enough.
// i had trouble cuz the type name needs to be fully qual'd
// too - including the namespace
Assembly ass = Assembly.GetExecutingAssembly();
string sName = ass.FullName; // we dont end up using this after all
AppDomain newDom = AppDomain.CreateDomain( "AdderDomain" );
object o = newDom.CreateInstanceAndUnwrap( "InteropTiming", "InteropTiming.LocalAdder" );
LocalAdder a = (LocalAdder)o;
Machine IP Address
string MyName = Dns.GetHostName();
string MyIP = Dns.GetHostByName(MyName).AddressList[0].ToString();
Didn't see a way to get the IP address without looking up the name in the DNS. Wonder what happens if the name is not in the DNS??
4.01.2002
Debugging COM+ Components
Not really .NET issue, but seems to come up a lot.
MSDN article
VC debugger, set the following:
- startup process = dllhost.exe
- command arguments = /ProcessID:{componentAppID}
ASP.NET and IIS Application Protection
Just a quick note that IIS Application Protection settings in Internet Services Manager do not apply to ASP.NET applications. All ASP.NET pages are serviced through aspnet_wp.exe (which is already a separate process from inetinfo.exe).
Each ASP.NET application gets its own AppDomain in aspnet_wp.exe
(quote from discuss.develop.com)
I'll answer my own question to some extent. In machine.config, there is an undocumented processModel attribute called "comAuthenticationLevel". This attribute seems to set the the Call Authentication Level for aspnet_wp.exe at the machine level.