.net
I just updated my post The Bloated World of Managed Code with baseline memory footprints for Console and Winforms apps in .NET 2.0. I'll admit I am a bit of a hypocrite when it comes to managed code apps. Now that tiny, native BitTorrent clients are available
c++
If you were about to throw out your C++ compilers because of my post on the productivity benefits of managed code and scripting languages, hold your horses. Although managed code is pretty darn fast, sometimes performance still comes first. As Ole Eichorn points out in the comments: [You said] "
.net
Here's some excellent, concise advice on troubleshooting performance in managed code [http://blogs.msdn.com/ricom/archive/2005/05/25/421926.aspx]. It all starts with peanut butter, naturally: > My last entry [http://blogs.msdn.com/ricom/archive/2005/05/23/421205.aspx] was some generic advice
performance
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
.net
Mark Russinovich recently posted a blog entry bemoaning the bloated footprint of managed .NET apps compared to their unmanaged equivalents. He starts by comparing a trivial managed implementation of Notepad to the one that ships with Windows: First notice the total CPU time consumed by each process. Remember, all I’
security
My personal turning point on the importance of managed code was in September 2001, when the NIMDA worm absolutely crushed our organization. It felt like a natural disaster without the “natural” part – the first notable port 80 IIS buffer overrun exploit. We got literally zero work done that day, and