Eric Lippert - What do you think of managed code? | TheChannel9Team

Jeremy W
that blogging guy

This is the kind of thing you want to point everyone too. Well done for getting Eric to open up about this. Love the talk about eliminating whole classes of bugs. For all the issues people do have with C#, garbage collection, etc, it solves a very real problem and makes real developers really productive.

jj5
Yeah. We got goth served.

What is your strategy for dealing with lapsed listeners?

Are your event publishers always shorter lived than the listeners, so you don't have to deal with them? Do you not use events (or delegates)? Do you unsubscribe in dispose?

Or when you say that you haven't debugged a memory leak in C# do you simply mean what you say? Not implying that you don't have memory leaks, just simply stating that you haven't debugged them..?

John.

object88
amplify.

jj5 wrote:

Or when you say that you haven't debugged a memory leak in C# do you simply mean what you say? Not implying that you don't have memory leaks, just simply stating that you haven't debugged them..?

In C#, you don't do manual allocation of memory. You don't keep manual track of object references. I.e., you don't even have to allocate an object to handle a reference, or call AddRef or Release. It's very much like VB in that regard, for better or for worse.

If the .NET subsystem takes care of all that stuff for you, you aren't given the opportunity to screw it up.

Of course, if .NET were to screw it up, we'd be in a world of hurt. Wink

The downside is that some .NET APIs are just slow. Take the Bitmap methods "GetPixel" and "SetPixel". Each call locks and unlocks some memory, which is an expensive operation. If you're changing or setting the pixels of a image one by one (in my case, grayscaling the image), you're hurting. So you have to use "unsafe" code, which gives you access to real memory pointers. Here, you have enough rope to shoot yourself in the foot, but at least you can do it quickly. You can operate on a whole region of memory by locking and unlocking once.

swythan

object88 wrote:

Take the Bitmap methods "GetPixel" and "SetPixel". Each call locks and unlocks some memory, which is an expensive operation.

Off topic, but I couldn't let it pass. In this particular case, that's not what's happening, IIUC.

GetPixel/SetPixel are GDI+ operations on the Bitmap object. They are handled by the unmanaged GDI+ code, which will (usually?) pass the operation off to your graphics driver. Your graphics driver is, of course, running in kernel mode, so user->kernel->user context switches are required for each call!

This is the same when using GDI+ from unmanaged C++, and was also the case using old GDI as well. Get/SetPixel is horrifically slow.

Oh, and the lapsed listeners problem is an interesting one. Conceptually similar (to me) to circular references in COM.

object88
amplify.

Ah, what was I thinking? I completely forgot that those calls were just GDI+ wrappers.

But the fact remains that there aren't fast managed code operations for manipulating bunches of pixels. You have to get to pointers, which is "unsafe". And, of course, once you get your pointers back, you have the chance to overrun all sorts of memory (speaking from expirience again).

So, the performance hit isn't because the code is managed, but rather because there isn't managed code that does the job well.

(Either that, or I'm completely lost regarding the meaning of managed code. In which case, please someone put me out of my misery.)