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

Posted: Apr 05, 2004 at 9:31 AM

By: The Channel 9 Team

(1)

14,955 Views

5 Comments

Video format

Option selected may change based on video formats available and browser capability.

Auto

Use our suggested format for this video.

Smooth Streaming

Adaptive bitrate streaming - little buffering but lower video quality at times of low bandwidth. Silverlight 5 required

Progressive

Traditional buffered video format. Silverlight 5 required

HTML5

For browsers that support H.264 MP4 or WebM video playback such as:
IE9+, Firefox 4+, Chrome 5+, or Safari 4+.

Flash

For browsers that have the Adobe Flash Player plugin installed.

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

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

kimss

Apr 07, 2004 at 4:54 AM

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.
Lwatson One ugly mug...

Apr 07, 2004 at 5:42 AM

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
object88 amplify.

Apr 07, 2004 at 1:27 PM

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.
Donkslayer Chaos,Panic and disorder - My work here is done

Jan 22, 2005 at 2:35 AM

Bump!
Corrector

Feb 27, 2010 at 5:52 PM

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?