http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Under the debugger, the assembly load is intercepted and work done there, which is why it is slow. the major difference is that in the DP case, we need to create an invocation, pass it to the interceptor, etc. There is actual work going on, whereas the non proxy case is just nop http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment12http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment12Fri, 22 Aug 2008 14:30:33 GMTWhat is the reason for the performance difference? I thought the proxy just inherits the given class. The actual performance PITA I have met with DP is the speed of _creating_ proxies, especially under debugger. http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment11http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment11Fri, 22 Aug 2008 14:23:34 GMTIt might be worth checking how parameters affect the results, although very few parameter payloads are that large... http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment10http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment10Fri, 22 Aug 2008 13:44:08 GMT Computer cycles cheap. Programmer cycles expensive. Tenthousand paid users that have to wait a second is more expensive. http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment9http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment9Fri, 22 Aug 2008 07:03:52 GMTThe run time performance seems good but to make the picture complete you should also add the first cold start, first warm start performance to see how much infrastructure it needs from the disk before anything visible happens. It really depends how stringent your startup performance goals are. Yours, Alois Kraus http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment8http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment8Fri, 22 Aug 2008 05:00:35 GMTThis is on 3.5, 32bit, no SP1 Take into account that the JIT may rewrite the code if it notice a common path http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment7http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment7Thu, 21 Aug 2008 20:47:39 GMTis this in 3.5? just curious because the CLR normally won't inline virtual calls so the time difference is umm curious. Are you running in 32bit or 64 bit? In 32bit ... class Program { static Trivial foo; static void Main(string[] args) { Trivial t = new Trivial(); t.EmptyVirtual(); Console.ReadLine(); } } when disassembled in release produces >>> 00DF0070 B9C0309100 mov ecx,9130C0h (MT: ConsoleApplication1.Trivial) 00DF0075 E8A21FB1FF call 0090201C (JitHelp: CORINFO_HELP_NEWSFAST) 00DF007A 8BC8 mov ecx,eax 00DF007C 8B01 mov eax,dword ptr [ecx] 00DF007E FF5038 call dword ptr [eax+38h] 00DF0081 E862755F78 call 793E75E8 (System.Console.get_In(), mdToken: 0600076e) 00DF0086 8BC8 mov ecx,eax 00DF0088 8B01 mov eax,dword ptr [ecx] 00DF008A FF5064 call dword ptr [eax+64h] 00DF008D C3 ret 00DF007C is the call to the virtual method (no inlining). Cheers, Greg http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment6http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment6Thu, 21 Aug 2008 20:43:38 GMT@Nathan I think it is quote of the day! http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment5http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment5Thu, 21 Aug 2008 20:34:35 GMTComputer cycles cheap. Programmer cycles expensive. http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment4http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment4Thu, 21 Aug 2008 20:32:24 GMTKnowing how your code performs is always a god thing. Perhaps in the future you will need that extra millisecond, perhps you will never need it. But at least now you know. http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment3http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment3Thu, 21 Aug 2008 19:25:12 GMT@Jason: Saying that reflection has great benefit at little cost is not 100% correct. The reflection used in Dynamic proxy is heavily optimized. Using reflection carelessly can still be quite costly. To continue the example above, try this naive chunk of reflection code and see how long it takes: trvial.GetType().GetMethod("EmptyStandard", BindingFlags.Instance | BindingFlags.Public).Invoke(foo, null); http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment2http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment2Thu, 21 Aug 2008 18:25:23 GMTWhile this is a non-issue for some developers, such as yourself. Most can actually benefit from this post. This may be the first time they have encountered the concept of premature/micro optimization. For us (yes, me included) this is actually mind bending information. I used to believe that reflection was evil and couldn't understand why anyone would use it. Now I see there is a great benefit and little cost. At least a much lower cost than I expected. This came from the belief faster is better and just not understanding the tools of my trade. So thank you for another great nugget of programming. http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment1http://ayende.com/3546/stupid-micro-benchmarking-proxy-performance#comment1Thu, 21 Aug 2008 18:08:43 GMT