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

The Discussion

• 

  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.

• 

  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

• 

  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. 
  

• 

  Bump!
  

• 

  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?