Re: Managed vs Unmanaged Bare Bones Performance Test
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Thu, 19 Apr 2007 15:09:32 -0700
On Thu, 19 Apr 2007 13:50:01 -0700, adhingra <adhingra@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[...]
To my surprise the managed code I generated in my test through C# was
lagging behind to a considerable degree when compared with the code generated by the C++ compiler.
I was wondering if someone can take a quick look at this and tell me why is this the case.
In addition to what I think are already some pretty good comments, I'd like to offer some other thoughts, particularly to expand on what Jon wrote.
First, without seeing the generated code it's hard to know for sure what you've measured. But it seems to me that at best, you've measured the cost of a function call, when in fact what would be much more interesting is the cost of doing actual work. At worst, you don't even have apple-to-apple performance comparisons between the two pieces of code, due to differences in what the compilers do with each version of the code.
Second, keep in mind that broadly there are two large classes of code: code that mostly uses the operating system to do its work, and code that is mostly computational in nature and so does most of its own work. The latter is much more likely to be affected by differences in the environment, and the latter is also much less common. One of the reasons that things like Virtual PC (which runs Windows on pre-Intel Macintoshes) and Rosetta (which runs pre-Intel Mac code on Intel Macintoshes) work so well is that the programs being run spend very little time in the code that needs to be translated.
Likewise, if you measure the performance difference between a task being done in C# versus C++, but then your real-world application spends most of its time executing code in the operating system, then the performance differences between C# and C++ are meaningless. If your code only spends 1% or less of its time executing the code you actually wrote, and the rest of its time either waiting on i/o (very common) or executing libraries in the operating system (also fairly common), then even if you have a 20X difference in performance (and frankly, I don't think a real-world comparison would result in that great a difference), you're only really looking at a 20% cost in the "slower" environment. There are a few classes of applications where this sort of difference matters. For others, it's entirely irrelevant.
I would advise making a decision on development environment based on what seems most appropriate to your application from a design and implementation perspective. There's no question that performance is also important, but it's been my experience that you achieve performance in practically any environment. Any gross performance problems are almost always addressable simply through better coding (that is, using the environment in the correct way). When you start trying to squeeze that last 5-10% of performance out, then sometimes you find yourself needing to move some of the more time-critical stuff into an environment with less-overhead. But generally, it's almost always better to use the environment that provides the tools you need for fastest, most efficient, and most bug-free development.
If you are writing applications that can benefit greatly by the services offered in .NET Framework (and most Windows applications fall into that class, mainly because of the vast difference in coding up a UI from scratch under Windows versus the simplicity of putting one together in ..NET), then C# and .NET are probably the right tools for the job. If .NET doesn't provide the kinds of components that would actually be all that useful to the kinds of operations your application needs to do, then don't waste time with it.
I can guarantee you that the real-world performance difference between ..NET and plain-vanilla C++ Windows programming is *nowhere near* a difference of 20X. The biggest thing I notice in my applications is start-up time, as the .NET Framework imposes a relatively large burden with respect to application initialization as compared to a straight Windows application. Once an application is running, I get practically identical performance to a similar one that might be written in plain Windows. Of course, this is because most of the time these applications aren't doing things that tax the .NET Framework.
Occasionally I run into issues where my code, due to inefficient design, spends too much time in my own code rather than letting the Framework handle things. For example, doing file i/o with buffers that are too small. In those situations, fixes are relatively easy.
And of course, every now and then you will run across something that is just plain costly in the .NET Framework, and which would run significantly faster without managed code. In those relatively uncommon cases, I think it's appropriate to shift the work to an unmanaged DLL that you call from the managed code, allowing the heavy lifting to be done in a fast, efficient way.
Pete
.
- References:
- Managed vs Unmanaged Bare Bones Performance Test
- From: adhingra
- Managed vs Unmanaged Bare Bones Performance Test
- Prev by Date: Re: Managed vs Unmanaged Bare Bones Performance Test
- Next by Date: Re: Managed vs Unmanaged Bare Bones Performance Test
- Previous by thread: Re: Managed vs Unmanaged Bare Bones Performance Test
- Next by thread: Re: Managed vs Unmanaged Bare Bones Performance Test
- Index(es):
Relevant Pages
|
