
4.05.2002
Interop & Remoting Timings
Based on calling simple int Adder( int x, int y ) implemented in various places.
So far - it's looking like calling through COM Interop layer is ~130 times slower than staying in managed code !?!? Is this right? Well, 130x slower, but still doing 1.3 million ops/second -- so that's usually fast enough. Calling a COM object from an incompatible CLR threading apartment is even more disasterous - only 12 thousand ops/second.
Remoting results show that calling a method on a Serializable object is no different than a local one (after paying for startup costs). An interesting outcome when comparing the two built-in protocols --- TCP protocol is 3x faster than HTTP on remote machine, 6x faster on local machine!
PIII 550 MHz CPU
256 MB RAM
Windows 2000 Server
Visual Studio .NET v 7.0.9466
.NET Framework v 1.0.3705
Your mileage may vary....
Curious how/why operations performed in another AppDomain did not suffer any slowdown due to marshalling...still under investigation - I'm probably doing something wrong?! :-)
400,000,000 repetitions of simple Add function.
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...