Managed code may be fat and slow, but it fares surprisingly well in Rico's C# port of Raymond Chen's C++ Chinese/English dictionary reader:
Sure, the C++ version eventually outperforms the managed code by a factor of 2x, but what's interesting to me-- and what this graph makes very clear-- is that the point of diminishing returns has set in well before that happens. As Rico notes:
So am I ashamed by my crushing defeat? Hardly. The managed code achieved a very good result for hardly any effort. To defeat the managed version, Raymond had to:
- Write his own file/io stuff
- Write his own string class
- Write his own allocator
- Write his own international mapping
Of course he used available lower level libraries to do this, but that's still a lot of work. Can you call what's left an STL program? I don't think so, I think he kept the std::vector class which ultimately was never a problem and he kept the find function. Pretty much everything else is gone.
So, yup, you can definitely beat the CLR. I think Raymond can make his program go even faster.
It's a pyrrhic victory once you divide the execution time by the development time of a top Microsoft C++ coder*. Now, for certain applications at the very tip of the development pyramid, this tradeoff may still make sense. But that list of apps gets shorter and shorter with every passing day.
* Raymond Chen, who has "fixed more Windows bugs than you've had hot dinners"
Rico has an interesting followup on memory footprint-- the 'real' cost of managed code:
a href="http://blogs.msdn.com/ricom/archive/2005/05/20/420614.aspx"http://blogs.msdn.com/ricom/archive/2005/05/20/420614.aspx/a
I did some basic "hello world" .NET memory footprint tests here:
a href="http://www.codinghorror.com/blog/archives/000271.html"http://www.codinghorror.com/blog/archives/000271.html/a
Jeff Atwood on May 28, 2005 10:49 AMThe comments to this entry are closed.
|
|
Traffic Stats |