Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Eric Lippert - What do you think of managed code?

Download

Right click “Save as…”

Hear Eric Lippert, software design engineer here at Microsoft (we know him as the "scripting guy" because he wrote VBScript and JScript technologies) talk about .NET code.

Follow the Discussion

  • Jeremy WJeremy 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.
  • jj5jj5 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.

  • object88object88 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.
  • 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.
  • object88object88 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.)
  • JizgJizg Null
    Beginnin Bump of Topic---Bump of Topic Complete
  • I have to agree that .net API's are a little slow. I am using them on my site cool science fair experiments and they seem to drag some with high bandwith usage.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.