Eric Lippert - Have you noticed a performance hit in .NET?

Download this episode

Download Video

Description

Eric Lippert takes on the belief that .NET code doesn't perform as well as code written with other methodologies.

Tag:

CLR

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      kimss
      I always find it interesting listening to people focusing on improving performance instead of waiting for new CPU power! I remember the days of the C64 when programming in machincode, I was doing a sideborder DYXPP (Different Y and X Pixel Possition - big thing in the old days).

      I remember the main "core" of the routine could have been done in around 50 looping lines, but it just took to much prosessing out of the huge C64 processor to maintain the framerate. I had to manually program all the DYXPP manipulations for all characters, I still remember braking the 8192 line barrier in the assembler... Man it was a lot of lines, but hell - it prosessed much faster.

      By the way, You can see the result in the old Demo archives that exist for the C64 all over the web, look in the PAL part of it after demoes from Cross and HTBFD (Hulter til bulter files demo). Some nostalgia there, hehe.
    • User profile image
      Lwatson
      I would say that you are right on with your assesment. Here at our offices we have embraced the complete use of the .Net CLR in VB and C#. Having converted all of our customers over from earlier implimentations on C++ and older VB code. The bottlenecks that exist in the environments offer much greater performance hits than the CLR does for day to day applications. (Databases across even broadband will bring a app to its knees long before garbage collectors and stringbuilders will)

      Spending ones time mimimizing those performance problems is a much more effective use for that scarce resource.

      my 2c
    • User profile image
      object88
      Lwatson wrote:

      Spending ones time mimimizing those performance problems is a much more effective use for that scarce resource.

      Indeed.  Working on a web application using SOAP, and those SOAP calls are the bottleneck.

      Still, it's more fun to optimize code bits.  Packing more data into SOAP calls to minimize the number of round trips is, well, not exciting.  Smiley
    • User profile image
      Donkslayer
      Bump!
    • User profile image
      Corrector

      And when you tune the algorithmic hotspots in your code, by rewriting them using unmanaged code, how will you handle the managed/unmanaged transitions that you will create, if they become the next bottleneck?

       

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.