views:

154

answers:

1

I have a 3rd party library and a simple benchmark test that I write by myself to test this library for performance. 3rd party library is C++/CLI .NET library and most code there is unmanaged. This library is assembled for .NET Framework 2.0. My benchmark test is managed C# code that adds little overhead to the library, only simple calls to the methods, subscription to event handlers, closing/opening connections etc. Library performs some operations in multiple working threads, it also deals with sockets.

Strange thing - when I compile by benchmark test with VS 2005 and when I do the same with VS 2008 - I got different performance values (VS 2008 is 10% better).

What can cause the performance increase, if all my code uses only .NET 2.0 features, no language/features or libraries from 3.5 are used. My benchmark project refers only System.dll and 3rd party dll, and benchmark code is absolutely the same in VS2005 and VS2008 projects ?

+2  A: 

Even if you only use 2.0 functionality (language? Library?), it can be that 3.5 JIT simply optimizes the code, or that some of the libraries are more optimized.

In other words: while the interfaces of 2.0 functions remain the same backwards compat, that doesn't have to be the case for the implementation. I assume the GC (and its locking is also constantly tweaked)

It will be very hard to figure out what exactly causes the difference. It could be as simple as some primitive functions (like memmove, search for byte/word in mem) being optimized for more recent cpu's.

Marco van de Voort
I considered as far as the core library for .NET 3.5 and .NET 2.0 is the same System.DLL 2.0.0.0 so no run-time differences should be there. Perhaps only compiler can add more optimization, by inlining more functions or whatever it can do...
Bogdan_Ch
(note I'm not a real or even half .NET expert, just guessing from experience with other toolchains) And that system.dll has all the same dependancies in the same versions? And in a JIT, the VM also can do things. The VM is not called a JIT _compiler_ for nothing.
Marco van de Voort